-> 계층을 잘 구성한다면 웹 계층, 영속성 계층에 독립적으로 도메인 로직을 작성할 수 있다. 하지만 이 책의 저자에 따르면 시간이 지날수록 소프트웨어를 더 변경하기 어렵게 만드는 허점을 노출한다고 한다.
웹 계층은 도메인 계층에, 도메인 계층은 영속성 계층에 의존하기에 자연스럽게 DB에 의존하게 된다. 즉, 모든 것이 영속성 계층을 토대로 만들어진다.
비즈니스 관점에서는 이러한 방식이 옳지 않고, 도메인 로직을 먼저 만들어야한다. 그리고 그 후 영속성 계층/ 웹 계층을 만들어야 한다.
위와 같이 작성하면, 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다.
서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고, 이로 인해 즉시로딩/지연로딩, DB 트랜잭션, 캐시 플러시 등 영속성 계층과 관련된 작업들을 해야 한다.
계층형 아키텍처에서 적용되는 유일한 규칙은, 특정 계층에서는 같은 계층 혹은 아래 계층에만 접근 가능하다는 것이다.
만약 상위 계층에 위치한 컴포넌트에 접근해야 하면, 컴포넌트를 계층 아래로 내려버리면 된다. 하지만 상위 접근이 계속해서 필요하다면 계속해서 아래로 보내게 된다.
계속해서 반복한다면 어떤 계층에도 속하지 않는 것처럼 보이는 헬퍼 컴포넌트나 유틸리티 컴포넌트들이 아래로 내려가게 되면서 영속성 레이어는 비대해지게 된다.
엔티티 필드를 하나만 조작하면 되는 경우, 웹 계층(컨트롤러)에서 바로 영속성 계층에 접근하면 도메인 계층을 건너 뛸 수 있다.
하지만 계층을 건너뛴다면 두 가지 문제점이 생긴다.
영속성 컴포넌트에 의존성이 많이 쌓이게 된다면 테스트의 복잡도를 높이고, 종속성을 이해하고 목을 만드는데 더 많은 시간이 걸리게 된다.
실제 개발을 하다보면, 기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기에 아키텍처는 코드를 빠르게 탐색하는데 도움이 되어야한다.
계층형 아키텍처는 도메인 로직이 여러 계층에 흩어지기 쉽고, 도메인/영속성 계층 모두가 접근할 수 있도록 하기 위해 영속성으로 내릴 수 있다. 따라서 코드를 탐색하는데에 힘들어질 수 있다.
또한 여러 개의 유스케이스를 담당하는 아주 넓은 서비스가 만들어질 수 있다. 이 한 서비스는 많은 의존성을 갖게 되고, 유스케이스를 책임지는 서비스를 찾기도 어려워 진다.
예를 들어 UserService에서 사용자 등록 유스케이스를 찾는 것보단 RegisterUserService를 바로 열어서 작업을 시작하는 것이 수월하다.
계층형 아키텍처에서 모든 것이 영속성 계층 위에 만들어지기에 영속성 계층 -> 도메인 계층 -> 웹 계층 순서로 만들어야 한다. 그렇기에 특정 기능은 동시에 한 명의 개발자만 작업할 수 있다.
즉, 동시에 작업한다면 충돌이 일어날 수 있다.
https://github.com/wikibook/clean-architecture
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=283437942