1-계층형 아키텍처의 문제는 무엇일까?

계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다

웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스레 데이터베이스에 의존하게 된다.
애플리케이션을 개발할 때 상태가 아니라 행동을 중심으로 모델링 해야한다.
- 행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스를 이끌어간다.
하지만 전통적인 계층형 아키텍처에서는 데이터베이스의 구조를 먼저 생각하고, 이를 토대로 도메인 로직을 구현하게 된다.
데이터베이스 중심적인 아키텍처가 만들어지는 가장 큰 원인은 ORM 프레임워크를 사용하기 때문이다.
- ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받는다.
- 일반적으로 ORM에서 관리되는 엔티티들은 영속성 계층에 둔다. 이렇게 되면 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다.
- 영속성 모델을 비즈니스 모델처럼 사용하게 되고 이로 인해 도메인 로직뿐만 아니라 즉시로딩/지연로딩, 데이터베이스 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 서비스에서 하게된다.

만약 상위 계층에 위치한 컴포넌트에 접근해야 한다면 간단하게 컴포넌트를 계층 아래로 내려버리려고 해버릴 것이다.
이렇게 되면 영속성 계층에서는 모든 것에 접근 가능하게 되어 점점 비대해진다.
- 어떤 계층에도 속하지 않는 것처럼 보이는 헬퍼 컴포넌트나 유틸리티 컴포넌트들이 이처럼 아래 계층으로 내릴 가능성이 큰 후보다.

계층형 아키텍처를 사용할 때 계층을 건너뛰고 시용하려고 할 수 있다.
- 문제점1: 도메인 로직을 웹 계층에 추가해서 애플리케이션 전판에 걸쳐 책임이 섞이고 핵심 도메인 로직이 퍼져나갈 확률이 높다.
- 문제점2: 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층도 mocking해야된다. 테스트 코드를 작성하는 것보다 종속성을 이해하고 mock을 만드는데 더 많은 시간이 걸리게 된다.

개발자는 기존 코드를 바꾸는 데 많은 시간을 쓴다.
- 기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기 때문에 아키텍처는 코드를 빠르게 탐색하는 데 도움이 돼야한다.
계층형 아키텍처는 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉬워, 새로운 기능을 추가할 적당한 위치를 찾는 일은 이미 어려워진 상태다.
또한 계층형 아키텍처는 여러 개의 유스케이스를 담당하는 아주 넓은 서비스가 만들어지기도 한다.
- 넓은 서비스는 테스트하기도 어려워지고 작업해야할 유스케이스를 책임지는 서비스를 찾기도 어려워진다.
UserService에서 사용자 등록 유스케이스를 찾는 대신 RegisterUserService를 바로 열어서 작업하도록, 고도로 특화된 좁은 도메인 서비스가 유스케이스 하나씩만 담당하게 된다면 작업이 수월해질 것이다.

계층형 아키텍처는 모든 것이 영속성 계층 위에 만들어지기 때문에 영속성 계층을 먼저 개발해야 하고, 그다음에 도메인 계층, 마지막으로 웹 계층을 만들어야 한다.
- 그렇게 때문에 새로운 유스케이스를 개발할 때 동시에 한 명의 개발자만 작업할 수 있다.
코드에 넓은 서비스가 있담녀 서로 다른 기능을 동시에 작업하기가 더욱 어렵다.
- 서로 다른 유스케이스에 대한 작업을 하게 되면 같은 서비스를 동시에 편집하는 상황이 발생할 수 있고, 이는 병합 충돌로 잠재적으로 이전 코드로 되돌려야 하는 문제를 야기하기 때문이다.