2장 : 의존성 역전하기
단일 책임원칙
“컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.“ (Single Reason to Change Principle)
(어떤 다른 이유로 소프트웨어의 변경이 있어도 이 컴포넌트에 대해서는 신경 쓸 필요 없다.)
단일 책임 위반할 경우
한 컴포넌트 변경이 다른 컴포넌트 실패의 원인으로 작용 가능하다.
변경 비용이 커져 변경이 어려워진다.
의존성 역전 원칙
“코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.
의존성 역전의 동작
엔티티는 도메인 객체를 표현하고 도메인 코드는 이 엔티티들의 상태를 변경하는 일을 중심으로 하기 때문에 먼저 엔티티를 도메인 계층으로 올린다. 영속성 계층의 리포지토리가 도메인 계층에 있는 엔티티에 의존하기 때문에 두 계층 사이에 순환 의존성이 생긴다.
DIP(Dependency Inversion Principle) 적용하는 부분으로, 도메인 계층에 리포지토리에 대한 인터페이스를 만들고, 실제 리포지토리는 영속성 계층에서 구현하게 하는 것이다.
클린 아키텍처
“설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다.” _ 로버트 C. 마틴
계층 간의 모든 의존성이 안쪽으로 향해 있다. (의존성 규칙)의존성 역전의 원칙의 도움으로 모든 의존성이 도메인 코드를 향하고 있음
코어
주변 유스케이스에서 접근하는 도메인 엔티티들이 있음
유스케이스 : 앞서 서비스라고 불렀던 것으로, 단일 책임을 갖기 위해 세분화 되어 있음 (이는 앞서 이야기했던 넓은 서비스 문제를 피할 수 있다.)
코어 주변
비즈니스 규칙을 지원하는 애플리케이션의 다른 모든 컴포넌트들 있음
ex. 영속성 제공, UI 제공
다른 서드파트 컴포넌트에 어댑터 제공
특징
도메인 코드에서는 어떤 영속성 프레임워크나 UI프레임워크가 사용되는지 알 수 없기 때문에 특정 프레임워크에 특화된 코드를 가질 수 없고 비즈니스 규칙에 집중할 수 있다.
이는 도메인 코드를 자유롭게 모델링할 수 있게 해준다.
외부 계층과 철저하게 분리 돼야 하므로 애플리케이션의 엔티티에 대한 모델을 계층에서 유지보수해야 한다.
육각형 아키텍처 (헥사고날 아키텍처)
포트와 어댑터 아키텍처라고도 불림
육각형 내부
도메인 엔티티
도메인 엔티티와 상호작용하는 유스케이스
육각형 외부
어댑터 : 애플리케이션과 상호작용
웹 브라우저와 상호작용하는 웹 어댑터
외부 시스템과 상호작용하는 어댑터
데이터베이스와 상호작용하는 어댑터
왼쪽의 어댑터 : 애플리케이션 코어를 호출 (주도하는 어댑터)
오른쪽의 어댑터 : 애플리케이션 코어에 의해 호출됨 (주도되는 어댑터)
포트
주도하는 어댑터 : 포트는 코어에 있는
유스케이스 클래스들에 의해 구현되고 호출되는 인터페이스주도되는 어댑터 포트는
어댑터에 의해 구현되고 코어에 의해 호출되는 인터페이스
DISCUSSION
Last updated