게층형 아키텍처 단점에 대한 대안
2-1. 단일 책임 원칙
하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 라는 해석보다는
컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.
에 더 가깝다.
책임 ⇒ 변경할 이유
아키텍처에서
소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경쓸 필요가 없어도 된다고 기대한다.
하지만 변경할 이유는 컴포넌트간의 의존성(직접/전이)을 통해서 쉽게 전파된다.
A →(의존) B,C,D,E ⇒ A는 B,C,D,E가 변경됨에 따라 같이 바뀌어야 한다.
2-2. 부수 효과에 관한 이야기
저자가 잘못 구조화된 소프트웨어를 변경하는 데 더 많은 비용을 지불한 경험
2-3. 의존성 역전 원칙
SRP
상위 계층은 하위 계층을 의존하기 때문에 변경할 여지가 더 많다.
실제로 영속성 계층이 변경된다고 해서 핵심 로직을 가지고 있는 도메인 계층도 변경해야 할까? 도메인 코드는 애플리케이션에서 가장 중요한 코드이다. 어떻게 이 의존성을 줄일 수 있을까?
코드상의 어떤 의존성이든 그 방향을 바꿀(역전시킬) 수 있다.
(의존성의 양쪽 코드를 모두 제어할 수 있을 때만)
- 영속성 계층이 도메인 계층을 의존하게 만들자.
- 도메인 계층 ➡ 영속성 계층 ⇒ 도메인 계층 ⬅ 영속성 계층
- 도메인 계층에 인터페이스를 도입한다.
서비스 [도메인 계층]
↙ ↘
엔티티 ➡ **레포지토리 인터페이스**
⬆ [영속성 계층]
엔티티 ⬅ 레포지토리 구현체2-4. 클린 아키텍처
비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적일 수 있다.
= 도메인 코드가 바깥으로 향하는 어떤 의존성도 없어야 한다.
(그림 출처: Credit: 도서출판 인사이트)
모든 의존성이 안쪽으로 향한다.
엔티티(코어) ⬅ 유스케이스 ⬅ 컨트롤러, 게이트웨이, 프레젠터 ⬅ 웹, 장치, 데이터베이스, UI, 외부 인터페이스
도메인 코드, 코어
- 다른 컴포넌트에 의존성을 가지지 않기 대문에 특정 프레임워크에 특화된 코드를 가질 수 없다.
- 비즈니스 규칙에 집중할 수 있다.
각 계층에서 엔티티 클래스를 가지고 유지보수해야한다. ⇒ 좋은 현상!
= 도메인 코드와 프레임워크간의 결합이 제거된 상태
2-5. 육각형(헥사고날) 아키텍처
클린 아키텍처보다 구체적인 원칙들
포트와 어댑터 아키텍처
(그림 출처: VROONG 테크블로그)
모든 의존성은 애플리케이션 코어(유스케이스, 도메인 계층)를 향한다.
헥사고날 아키텍처 또한 계층으로 구성되어 있다.
- 애플리케이션과 다른 시스템 간 번역을 담당하는 어댑터 (최상단 계층)
- 포트, 유스케이스 구현체 = 애플리케이션의 인터페이스 (애플리케이션 계층)
- 도메인 엔티티 (가장 안쪽 계층)
2-6. 유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
기존의 도메인 계층과 영속성/UI 계층간의 의존성을 역전시킨다.
도메인 계층(애플리케이션의 주요 코드)은 다른 컴포넌트를 의존하지 않게 된다.
SRP 원칙에 의해 도메인 계층은 변경할 이유가 적어진다.
각 계층은 더 자유롭게 모델링될 수 있고, 유지보수성이 좋아진다.
느낀 점
SRP
- p13 컴포넌트를 변경할 이유는 한 가지여야 한다. 하지만 컴포넌트들간 의존성을 통해 컴포넌트를 변경할 가능성이 높아진다.
- 이 소단원의 의미: 의존성을 줄여라 X → 의존성을 역전시켜라!
질문
- p17 도메인 계층과 영속성 계층의 의존성을 역전시키기 위해 각 계층에 각각 엔티티를 위치시켰다. 도메인 계층에 있는 엔티티와 영속성 계층의 ORM-Managed 엔티티는 어떻게 다를까
- p19 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다.
단일 책임 원칙을 지키기 위해 의존성을 없애고, 의존성을 없애기 위해 하나의 비즈니스 모델을 여러 계층에 모두 존재하게 한다.- 이 방식이 유지보수가 가능할까? 만약 한 모델을 개발자가 빼먹는다면?
- 객체지향의 재사용성이라는 장점을 살리지 못하는 것 같다.
- p19 JPA에서는 ORM이 관리하는 엔티티에 인자가 없는 기본 생성자를 추가하도록 강제한다. 이것이 바로 도메인 모델에는 포함해서는 안 될 프레임워크에 특화된 결합의 예다.
- 기본 생성자를 가지지 않는 JPA의 엔티티 없이 어떻게 해당 프레임워크를 사용하는가?
일단 위의 질문들 모두 예시를 봐야할 것 같다.
