계층형 아키텍쳐의 문제
위 그림은 일반적인 3 계층 아키텍처를 표현한다.
- 웹 계층에서 요청을 받아 도메인 or 비즈니스 계층에 있는 서비스로 요청을 보낸다.
- 서비스에서는 비즈니스 로직을 수행하고, 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출한다.
이 계층형 아키텍처의 문제가 무엇인지 정리한다.
데이터베이스 주도 설계 유도
계층형 아키텍처의 토대는 데이터베이스이다.
웹 계층은 도메인 계층에, 도메인 계층은 영속성 계층에 의존하기 때문이다.
계층형 아키텍처에서는 데이터베이스의 구조를 먼저 생각하고, 이를 토대로 도메인 로직을 구현한다.
ORM 프레임워크를 계층형 아키텍처와 결합하면, 영속성 계층과 도메인 계층 간 강한 결합이 생긴다.
위와 같이, ORM 에 의해 관리되는 엔티티들은 영속성 계층에 둔다.
계층은 아래 방향으로만 접근 가능해서, 도메인 계층에서는 엔티티에 접근 가능하고 엔티티를 사용한다.
서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되는 것이다.
지름길을 택하기 쉬움
만약 상위 계층에 위치한 컴포넌트에 접근해야하면, 컴포넌트를 계층 아래로 내려버린다.
위 그릠은, 비대해진 영속성 계층을 나타낸다.
어떤 계층에도 속하지 않은 것처럼 보이는 핼퍼, 유틸리티 컴포넌트가 아래 계층으로 내려온 것이다.
테스하기 어려움
계층을 건너뛰는 것이 가능하다.
웹 계층에서 영속성 계층에 바로 접근해서 엔티티의 필드를 직접 조작하는 경우가 있다.
그러면, 도메인 로직이 웹 계층에 섞여, 책임이 섞이고 핵심 도메인 로직이 퍼진다.
또한, 웹 계층 테스트에서 도메인 계층 뿐만 아니라 영속성 계층도 mocking 해야해서 테스트가 복잡해진다.
유스케이스를 숨김
도메인 로직이 여러 계층에 흩어지기 쉽다.
- 도메인 계층을 생략해서 웹 계층에 존재할 수 있고,
- 도메인 계층과 영속성 계층에 모두 접근하도록 특정 컴포넌트를 아래로 내렸으면, 영속성 계층에 존재할 수 도 있다.
그러면, 새로운 기능을 추가할 적당한 위치를 찾기 어렵다.
또한, 여러 유스케이스를 담당하는 아주 넓은 서비스가 만들어 질 수 있다.
동시 작업이 어려움
영속성 계층을 먼저 개발하고, 도메인 계층 그리고 마지막으로 웹 계층을 만들어야한다.
그래서, 동시에 한 명의 개발자만 작업 가능하다.
만들면서 배우는 클린 아키텍처 <톰 홈버그>