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

계층형 아키텍쳐란?

웹, 도메인, 영속성 계층으로 이루어져있다.

웹 계층에서는 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다.

서비스는 비즈니스 로직과 도메인 엔티티의 상태 조회 및 변경을 위해 영속성 계층의 컴포넌트를 호출한다.

1. 데이터 베이스 주도 설계를 유도

• 웹 계층은 → 도메인 계층, 도메인 계층은 → 영속성 계층에 의존한다.
• 데이터 베이스 중심 아키텍쳐가 만들어지는 큰 원인은 ORM을 사용하기 때문이다. ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 둔다. 이를 통해 영속성 계층과 도메인 계층에 강한 결합이 생긴다.
• 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고, 도메인 로직 뿐만 아니라, 즉시 로딩, 지연 로딩, 데이터 베이스 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 해야만 한다.

2. 지름길을 택하기 쉬워진다.

• 전통적인 계층형 아키택쳐에서 적용 되는 규칙으로, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다는 규칙이 있다.
• 영속성 계층에서는 모든 것에 접근 가능하기 때문에, 시간이 지나면서 점점 비대해진다. 즉, 어떤 계층에도 속해있지 않는 것처럼 보이는 헬퍼 컴포넌트나 유틸리티 컴포넌트 들이 아래 계층으로 내려올 수 있다.
• 이를 위해, 아키텍쳐 규칙을 강제할 수 있는데, ‘강제한다’는 의미는 해당 규칙이 깨졌을 때 빌드가 실패하도록 만드는 규칙을 의미한다.

3. 테스트하기 어려워진다.

만약 엔티티의 한 필드만을 조작한다면, 웹에서 영속성 계층을 의존하게 된다. 즉, 직접적으로 도메인 계층을 건드리지 않는다.

이는, 다음과 같이 두가지 문제점이 있다.

1. 도메인 로직을 웹 계층에 구현하게 된다.
   1. 유스 케이스가 확장된다면, 웹 계층에 구현하는 일이 많아질 테고 책임이 섞일 수 있다.
2. 웹 계층 테스트에서 영속성 계층을 모킹하여야 한다.
   1. 단위 테스트의 복잡도가 높아진다. 이는 테스트 코드를 작성하는 것 보다, 종속성을 이해하고 mock을 만드는 데 더 많은 시간이 걸린다.

4. 유스 케이스를 숨긴다.

계층형 아키텍쳐는 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉽다.

• 도메인 계층을 생략한다면, 웹 계층에 존재할 수 있고, 도메인 계층과 영속성 계층 모두에서 접근할 수 있다면, 영속성 계층에 존재할 수 있다.

계층형 아키텍쳐는 여러 개의 유스 케이스를 담당하는 넓은 서비스를 만든다.

다음과 같이 넓은 서비스는 영속성 계층에 많은 의존성을 갖게 된다. 이는, 서비스를 테스트하기 어려워지고, 유스케이스를 책임지는 서비스를 찾기 어려워진다.

 

5. 동시 작업이 어려워진다.

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다.

인력을 더해서, 기간이 빨라지려면 아키텍처가 동시작업을 지원해야한다. 계층형 아키텍쳐에서는 동시작업을 지원하기 어렵다.

계층형 아키텍쳐는 영속성 계층 위에 만들어 지기 때문에, 영속성 계층을 개발한 후에, 도메인 계층 개발 그리고 마지막으로 웹 계층을 만든다.

물론 인터페이스를 먼저 같이 정의하고, 이 인터페이스 들로 작업하면 된다고 이야기 할 수 있다. 하지만, 이는 데이터베이스 주도 설계를 하지 않는 경우에만 가능하다. 왜냐하면 데이터 베이스 주도 설계는 영속성 계층과 도메인 계층이 섞여있기 때문이다.

또한 넓은 서비스가 존재한다면, 동시 편집과 더불어 병합 충돌로 이어진다.

유지보수 가능한 소프트웨어를 만드는 방법?

계층형 아키텍쳐 또한 추가적인 규칙 적용을 통해, 코드를 쉽게 변경 또는 추가할 수 있다.