클린 아키텍처 요약

만들면서 배우는 클린 아키텍처 - 톰 홈버그

클린코드책 다음으로 클린 아키첵처를 정리해보려고 한다.
 
 

01. 계층형 아키첵처의 문제는 무엇일까?

- 계층형 아키텍처

소스코드를 역할과 관심사에 따라 계층으로 분리한 아키텍처

잘 만들어진 계층형 아키텍처는 선택의 폭을 넓히고, 변화하는 요구사항과 외부요인에 빠르게 적응할 수 있게 해준다.
 
 

- 문제

1. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.
웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 데이터베이스에 의존하게 되므로, 계층 사이에 강한 결합이 생긴다.
에를들어, ORM을 사용하게되면 도메인 계층에서 엔티티에 접근할 수 있는데 이렇게되면 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되어 서비스에서 영속성 관련된 작업들을 하게되는데, 이러면 영속성 코드가 도메인 코드에 녹아들어서 둘 중 하나만 바꾸는 것이 어려워진다.
 
2. 지름길을 택하기 쉬워진다.
계층의 아키텍처의 유일한 규칙은 '특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다' 인데, 상위 계층에 위치한 컴포넌트에 접근하기 위해 쉬운방법인 호출하는 컴포넌트보다 아래 계층으로 내려버리는 것을 선택할 수 있다.
이렇게 계속 하다보면 하위의 영속성 계층이 점점 커지게 된다.
 
3. 테스트하기 어려워진다.
계층형 아키텍처를 사용할때 웹 계층에서 영속성 계층으로 바로 접근하는 등 계층을 건너뛰어서 사용하게 되는 경우가 발생하는데,

이렇게 사용하게되면 책임이 섞이고 도메인 로직을 코드 여기저기에 흩어지게 만들며, 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층도 모킹해야 하므로 단위 테스트의 복잡도가 올라간다.
 
4. 유스케이스를 숨긴다.
아키텍처는 코드를 빠르게 탐색하는데 도움이 되어야 한다.
계층형 아키텍처는 도메인 서비스의  '너비'에 관한 규칙을 강제하지 않는다.

• 포트와 어댑터 아키텍처
• 가장 바깥쪽 계층에 애플리케아션과 다른 시스템을 연결하는 어댑터가 있고, 다음으로

그렇기 때문에, 아주 넓은 서비스가 만들어지기도 하는데, 넓은 서비스는 영속성 계층에 많은 의존성을 갖게 되게 때문에 코드 상에서 특정 유스케이스를 찾기 어렵게 만든다.
=> 서비스가 유스케이스를 적게 담당할수록 코드의 유지보수가 쉬워진다.
 
5. 동시 작업이 어려워진다.
계층형 아키텍처는 모든 것이 영속성 계층에 만들어지고 그다음에 도메인 계층, 웹 계층 순서로 만들어지기 때문에 특정 기능은 동시에 한 명의 개발자만 작업할 수 있다 (동시에 여러명이 작업하게 되면 충돌남)
 

---

 

02. 의존성 역전하기

계층형 아키텍처의 문제점에 대한 대안
SOLID 원칙 준수하기
- SRP (Single Responsibility Principle) : 단일 책임 원칙
클래스는 하나의 책임만 가져야 하며, 변경의 이유도 하나여야 한다.
 
- OCP (Open/Closed Principle) : 개방 - 폐쇄 원칙
확장에는 열려있고, 변경에는 닫혀있어야 한다.
새로운 기능을 추가하거나 변경할 때 기존 코드를 수정하지 않고도 확장할 수 있어야 한다
 
- LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
프로그램에서 부모 클래스의 객체를 자식 클래스로 교체해도 프로그램의 동작은 동일해야 한다.
 
- ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
 
- DIP (Dependency Inversion Principle) : 의존성 역전 원칙
고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 추상화된 것에 의존해야 한다.
코드상의 어떤 의존성이든 그 방향을 바꿀 수 있다.
 
클린 아키 텍처
게층간의 의존성 방향은 모두 아래로 향해야한다.
 
육각형 아키텍처 (헥사고날 아키텍처)