레이어드(계층형) 아키텍처

유사한 기능들을 같은 계층으로 묶어 관리하는 방식의 아키텍처 구조

Service 계층이 거의 모든 일을 다 처리한다.

장점

• 기능 개발을 할 때, 가시적으로 무언가를 만들기에 가장 쉽다.

단점

• DB 주도 설계 유도한다.
  -> 사실은 use-case 를 먼저 파악하는게 우선
• 의존성에 대한 고민을 유도하지 않는다.
• 동시 작업이 어렵다.
• 도메인이 죽는다.
• 규모가 커질수록 확장성이 떨어진다.

결과적으로 절차지향적 사고를 유도하고, 낮은 Testability, SOLID 원칙이 지켜지지 않는다.

레이어드(계층형) 아키텍처 개선하기 (1)

서비스에서 핵심 로직을 Domain 레이어로 분리해보자.

서비스 레이어의 변경된 사항

이전에는 서비스 레이어가 모든 로직 처리를 담당했다면,
수정 후에는 도메인을 Repository에서 가져와 책임을 위임한다.

도메인 레이어의 특징

• 객체지향(OOP) 스러운 도메인들이 협력하는 곳
• lombok 을 제외한 어노테이션이 없다.
• 계층간 연결된 의존성이 없다.
  (위 그림을 보면, 도메인에서 나가는 화살표가 없다.)

레이어드(계층형) 아키텍처 개선하기 (2)

1에서 서비스와 도메인을 분리했다.
하지만, 여전히 서비스는 JpaRepository에 의존하며, 강결합 되어있다.
이를 다시 분리해보면 아래와 같다.

Presentation 계층에 있는 Service Interface와
Application 계층에 있는 Repository Interface 를 포트(Port)라고 한다.
* 각 구현체는 어댑터(Adaptor) 라고 하여, 포트-어댑터 패턴으로도 불린다.

이제 서비스 계층은 더이상 Jpa 에 의존하지 않는다.

헥사고날 아키텍처

육각형 아키텍처 또는 포트 및 어댑터 아키텍처는 소프트웨어 설계에 사용되는 아키텍처 패턴입니다.
포트와 어댑터를 통해 소프트웨어 환경에 쉽게 연결할 수 있는 느슨하게 결합된 응용 프로그램 구성 요소를 만드는 것을 목표로 합니다. - 위키백과

헥사고날 아키텍처는 의존성 역전 (포트-어댑터 패턴)
우리는 이미 레이어드 아키텍처를 헥사고날 아키텍처로 변환했다. (언제?!)

위에 2번에서 개선된 아키텍처의 이미지를 다시 보자.
이 그림을 포트-어댑터로 표현하면
와 같고, 이걸 일렬로 쭉 늘려보자.

이 상황에서, 경계만 그려준다.

그리고, 가운데 부분을 아래로 늘려준다.

헥사고날 아키텍처가 완성됐다.

장점

• 외부에서, 도메인으로 향하는 방향이 단방향으로 유지된다.
• 외부 세계 (Input, Output Adaptor)는 관심이 없다. 오로지 도메인에만 집중한다.
  Input Adaptor (= Web Adaptor) : 스프링 > 스프링에서 알아서 잘 테스트 했겠지,,,
  Output Adaptor (= DB Adaptor, Infrastructure): JPA, Hibernate > 거쪽에서 알아서 잘 테스트 했겠지,,,
• 테스트에 용이하다.

단점

• 초기 비용이 너무 크다.
• 클래스가 하나 늘어날 때마다 들어가는 비용이 크다.