✅ 02. 의존성 역전하기
🔗 단일 책임 원칙
컴포넌트를 변경하는 이유는 오직 하나 뿐이어야 한다.
단일 책임 원칙의 정의를 살펴보았을 때, 책임은 '오로지 한 가지 일만 하는 것'보다, '변경할 이유'로 해석해야 한다. 하지만 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해 쉽게 전파된다.
🔗 의존성 역전 원칙
계층형 아키텍처에서 계층 간 의존성은 다음 계층인 아래 방향을 가리킨다. 단일 책임 원칙을 고수준에서 적용할 때, 상위 계층들이 하위 계층들에 비해 변경할 이유가 더 많다는 것을 알 수 있다.
그러므로 도메인 계층 -> 영속성 계층 의존성 때문에, 영속성 계층을 변경할 때마다 잠재적으로 도메인 계층도 변경해야 한다. 그러나 도메인 계층은 애플리케이션에서 가장 중요한 코드이기에 영속성 코드가 바뀐다고 해서 도메인 코드까지 바꾸는 건 좋지 않아 보인다.
따라서 도메인 <- 영속성 와 같이 의존성을 역전시키고, 도메인 코드를 변경할 이유의 개수를 줄여야 한다.
- 엔티티는 도메인 객체를 표현하고, 도메인 코드는 이 엔티티들의 상태를 변경하는 일을 하기에 도메인 계층으로 올린다.
- 도메인 계층에 레포지토리에 대한 인터페이스를 만들고, 실제 레포지토리는 영속성 계층에 구현하게 한다.
🔗 클린 아키텍처
이 아키텍처에서 가장 중요한 규칙은 의존성 규칙이다. 계층 간의 모든 의존성이 안쪽으로 향해야 한다.
- core(도메인 계층 + 애플리케이션 계층)에는 주변 유스케이스에서 접근하는 도메인 엔티티들이 있다.
- 코어 주변으로, 비즈니스 규칙을 지원(영속성 제공, UI제공)하는 애플리케이션의 컴포넌트를 확인할 수 있다.
- 바깥쪽 계층들은 다른 서드파티 컴포넌트에 어댑터를 제공할 수 있다.
- 도메인 코드에서는 어떤 프레임워크가 사용되는지 알 수 없기에 특정 프레임워크에 특화된 코드를 가질 수 없고, 비즈니스 규칙에 집중할 수 있다.
하지만 클린 아키텍처는 도메인 계층이 영속성이나 UI 같은 외부 계층과 철저히 분리돼야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수 해야한다. 예를 들어, 도메인 계층은 영속성 계층을 모르기에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층에서 함께 사용할 수 없고 서로 데이터를 주고 받을 때, 두 엔티티를 서로 변환해야 한다.
🔗 육각형 아키텍처(헥사고날 아키텍처)
- 육각형 안에는 Entity와 Use Case가 있다. 육각형 외부로 향하는 의존성은 없고, 모든 의존성은 코어를 향한다.
- 육각형 밖에는 애플리케이션과 상호작용하는 어댑터가 존재한다.
- 왼쪽의 어댑터는 애플리케이션 코어를 호출하기에 애플리케이션을 주도한다. (driving adapter)
- 오른쪽의 어댑터는 애플리케이션 코어에 의해 호출되므로 주도되는 어댑터다. (driven adapter)
애플리케이션 코어와 어댑터 간의 통신이 가능하기 위해선, 포트가 제공되어야 한다. driving adapter에게는 포트가 코어가 구현을 하고, driven adapter는 어댑터에 의해 구현된다.
🔗 유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
의존성을 역전시켜, 도메인 코드가 바깥쪽 코드에 의존하지 않게 함으로써 도메인 로직의 결합을 제거하고 코드의 변경 이유를 줄인다.
도메인 코드는 비즈니스 문제에 맞게 모델링될 수 있고, 영속성 코드와 UI 코드도 각각 맞게 모델링될 수 있다.
