TIL

01. 계층형 아키텍처의 문제는 무엇일까

게층형 아키텍처에선 모든 것이 영속성 계층을 토대로 만들어지기 때문에 다양한 문제를 초래한다.
대부분의 애플리케이션은 비즈니스를 관장하는 규칙이나 정책을 반영한 모델을 만드는데 이 때 상태가 아닌 행동을 중심으로 모델링한다.
- 상태도 중요하지만 행동이 상태를 바꾸는 주체이다.
다른 무엇보다도 도메인 로직을 먼저 만들어야 한다.
- 그래야 우리가 로직을 제대로 이해했는지 확인할 수 있다.
- 하지만 계층형 아키텍처에선 의존성 방향에 따라 데이터베이스 구조를 먼저 생각하고 도메인 로직을 구현하게 된다.
JPA와 같은 ORM 프레임워크를 사용하면서 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받는다.
- 위와 같은 구조로는 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다.
- 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 된다.
- 즉시로딩/지연로딩, 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 서비스에서 처리해야 한다.
- 영속성 코드가 도메인 코드에 녹아들어가서 둘 중 하나만 바꾸는 것이 어려워진다.

계층형 아키텍처에서의 유일한 규칙은 ‘특정 계층에서는 같은 계층의 컴포넌트나 아래 계층에만 접근 가능하다’는 것이다.
만약 상위 계층에 위치한 컴포넌트에 접근해야 한다면 간단하게 컴포넌트를 계층 아래로 내려버리면 된다.
이러한 지름길을 사용하면서 시간이 지나다 보면 영속성 계층이 비대해질 것이다.
어떤 계층에도 속하지 않는 헬퍼 컴포넌트나 유틸 컴포넌트들이 아래 계층으로 내릴 가능성이 큰 후보들이다.
‘지름길 모드’를 끄고 싶다면 추가적인 아키텍처 규칙을 강제해야 하는데, ‘강제한다’는 것은 코드 리뷰 등이 아닌 규칙이 깨졌을 때 빌드가 실패하도록 만드는 규칙을 말한다.

계층형 아키텍처를 사용할 때 흔히 계층을 건너뛰는 일이 발생한다.
- ex) 엔티티의 필드를 하나만 조작하면 되는 경우 웹 계층에서 바로 영속성 계층에 접근하면 도메인 계층을 건드릴 필요가 없다. (이런 유혹을 받게 된다)
단 하나의 필드를 조작하는 것에 불과하더라도 도메인 로직을 웹 계층에서 구현하게되면 앞으로의 유스케이스 확장에서 더 많은 도메인 로직이 웹 계층에 추가되어 핵심 도메인 로직이 퍼져나갈 확률이 높다.
웹 계층 테스트에서 도메인, 영속성 계층도 모킹하거나 테스트해야 한다.
- 단위 테스트 복잡도가 올라간다.
- 테스트 설정이 복잡해진다.
웹 컴포넌트의 규모가 커지면 테스트 복잡도를 늘리고 테스트 코드 작성보다 목을 만드는데 더 많은 시간이 걸리게 된다.

일반적으로 새로운 코드를 짜는 시간보다 기존 코드를 바꾸는 데 더 시간을 쓴다.
기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기에 아키텍처는 코드를 빠르게 탐색하는 데 도움이 돼야 한다.
- 하지만 계층형에서는 앞서 말했듯이 도메인 로직이 여러 계층에 흩어지기 쉽다.
심지어 계층형에선 도메인 서비스의 ‘너비’에 관한 규칙을 강제하지 않기에 여러 유스케이스를 담당하는 넓은 서비스가 만들어지기도 한다.
- 넓은 서비스는 영속성 계층에 많은 의존성을 갖게 되고, 웹 계층의 많은 컴포넌트가 이 서비스를 의존하게 된다.
- 테스하기 어렵고 작업해야할 유스케이스를 책임지는 서비스를 찾기도 어려워진다.
고도로 특화된 좁은 도메인 서비스가 유스케이스 하나씩만 담당하게한다면 일이 수월해질 것이다.
- ex) UserService 대신 RegisterUserService

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다. «맨머스 미신: 소프트웨어 공학에 관한 에세이», 프레더릭 P. 브룩스