1. 계층형 아키텍처이란

계층형 아키텍처 : 웹 -> 도메인 -> 영속성
웹 : 요청을 받는다
도메인 : 비지니스 계층에 있는 서비스로 필요한 로직을 수행한다.
영속성 : 도메인 엔티티의 상태를 조회하거나 변경하는 부분

특징

• 견고한 아키텍처 패턴
• 웹 계층이나 영속성 계층에 독립적으로 도메인 로직 작성 가능
• 가능하다면 도메인 로직에 영향없이 웹 계층과 영속성에 사용된 기술 변경 가능
• 기존 기능에 영향을 주지 않고 새로운 기능 추가도 가능
• 선택의 폭을 넗히고, 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다.

2. 계층형 아키텍처의 문제

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

• 웹 -> 도메인 -> 영속성 으로의 의존성 방향은 자연스럽게 데이터베이스에 의존하게 된다.
• 즉 모든것이 영속성 계층을 토대로 만들어진다.
• ORM 프레임워크(JPA, Hibernate)의 사용은 비즈니스 규칙을 영속성 관점과 섞고 싶게 만든다.
• 상태가아닌 행동을 중심으로 모델링 해야 하지만 도메인 로직이 아닌 데이터베이스 토대로 아키텍처를 만들게 된다.

• 계층형 아키텍처의 의존성 방향으로 도메인 계층에서 엔티티에 접근해야 한다.
• 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다.
• 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되면서 즉시로딩/지연로딩, 트랜잭션, 캐시 플러시 등 영속성 계층과 관련된 작업을 하게 된다.
• 영속성 코드가 도메인 코드에 녹아들어가면서 둘중 1개만 바꾸는 것이 어려워진다.
• 유연하고 선택의 폭을 넓혀준다는 계층형 아키텍처 목표와 반대가 되는 상황

2. 깨진 유리창

계층형 아키텍처의 유일한 규칙은 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다이다.

• 만약 상위 계층에 위치한 컴포넌트에 접근해야 한다면 컴포넌트를 계층아래로 내여버리면 된다.
• 누군가 지금길을 택하게 되면 깨진 창문 이론으로 인해 점점 더 유지보수가 어려운 코드로 바뀌게 된다.

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

• 누군가 웹(컨트롤러) 에서 도메인계층을 넘겨 영속성(레포지토리)를 사용할 수 있다.
  • 이로 웹 전반의 책임 이 섞이게 된다.
  • 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층도 모킹을 해야 되 단위 테스트의 복잡도가 올라간다.
• 깨진 유리창 법칙문제이다.

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

• 도메인 로직이 여러 계층에 흩어지게 되면 유지보수가 어려워진다(한번 원칙이 깨지면 돌이키기 어렵다)
• 서비스의 너비를 강제하지 않으므로 여러 유스케이스를 담당하는 아주 넓은 서비스가 만들어질 수 있다.
  • 서비스 계층의 책임 분리가 굉장히 중요해진다.
  • 실제 여러 서비스들이 서로 참조하게 되면 설계에 대한 고민이 많아지게된다 - 예)퍼사드 패턴 적용

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

• 모든 것이 영속성 계층위에 만들어지기 때문에 영속성 계층을 먼저 개발해야 한다.
• 그 후 도메인 계층 그 후 웹 계층을 만들어야 한다.
• 특정 기능은 동시에 한명의 개발자만 작업하게 된다.
• 데이터베이스 주도 설계를 하지 않을 때 개발자들이 각자 먼저 인터페이스를 정의하고 실제 구현을 기다릴 필요 없이 인터페이스로만 작업이 가능하다.(데이터베이스 주도 설계는 영속성 로직이 도메인 로직과 너무 뒤섞여 개별적 작업이 불가능하다)