의존성 역전
계층형 아키텍처의 대안에 대해 정리한다.
단일 책임 원칙
단일 책임 원칙이란, 컴포넌트를 변경하는 이유는 오직 하나 뿐이어야한다는 것이다.
변경할 이유는, 컴포넌트 간 의존성을 통해 쉽게 전파된다.
컴포넌트 A 는 다른 컴포넌트 들에 의존하고, 컴포넌트 B 는 의존하는 것이 전혀없다.
컴포넌트 B 를 변경할 유일한 이유는 새로운 요구 사항에 의해 B 의 기능을 바꿔야할 때 뿐이다.
컴포넌트 A 는 다른 컴포넌트가 바뀌면 같이 바뀐다.
하나의 컴포넌트를 바꾸는 것이, 다른 컴포넌트의 실패 원인이 될 수 있다.
의존성 역전 원칙
계층형 아키텍처에서 계층 간 의존성은 항상 다음 계층인 아래 방향을 가리킨다.
그래서, 영속성 계층을 변경할 때마다, 도메인 계층도 변경해야한다.
이 의존성을 제거해보자.
- 도메인 코드는 엔티티의 상태를 변경하는 일을 중심으로 하기 때문에 엔티티를 도메인 계층으로 올리자.
- 그런데 이렇게 하니, 영속성 계층의 repository 가 도메인 계층의 엔티티에 의존하게 되어 circular dependency 가 발생한다.
- 이 부분에 DIP 를 적용하자. 도메인 계층에 repository interface 를 두는 것이다.
클린 아키텍처
클린 아키텍처에서는, 비즈니스 규칙의 테스트를 쉽게 하고, 비즈니스 규칙이 프레임워크, DB, UI, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적이다.
이것은, 도메인 코드가 바깥으로 향하는 의존성이 없어야 가능하다.
대신, 의존성 역전 원칙으로 모든 의존성이 도메인 코드를 향한다.
코어에는, 주변 유스케이스에서 접근하는 도메인 엔티티들이 있다.
‘유스케이스’ 는 계층형 아키텍처에서의 ‘서비스’ 이다.
단일 책임 원칙을 가지기 위해 세분화 되어 넓은 서비스 문제를 피한다.
클린 아키텍처에서는, 도메인 계층이 영속성이나 UI 같은 외부 계층과 철저하게 분리되어야한다.
그래서, 애플리케이션의 엔티티에 대한 모델을 각 게층에서 관리한다.
육각형 아키텍처
육각형 아키텍처는, 추상적인 클린 아키텍처를 구체적으로 만들어준다.
육각형 안에는 도메인 엔티티와, 도메인 엔티티와 상호작용하는 유스케이스가 있다.
육각형에서 외부로 향하는 의존성은 없다.
클린아키텍처에서 제시한 의존성 역전 원칙으 그대로 적용되어서, 모든 의존성은 코어로 향한다.
육각형 밖에는 애플리케이션과 상호 작용하는 어뎁터 들이 있다.
(웹 브라우저와 상호작용하는 웹 어뎁터, 외부 시스템과 상호작용하는 어뎁터, DB 와 상호작용하는 어뎁터..)
만들면서 배우는 클린 아키텍처 <톰 홈버그>