지난 시간엔 레이어드 아키텍처를 알아봤다.
이번에 소개할 아키텍처는 DDD의 대명사 헥사고날 아키텍처이다.

헥사고날 아키텍처란?

DDD(Domain Driven Design)를 구현할 때 가장 자주 소개되는 아키텍처이다.
헥사고날 아키텍처의 핵심은 비즈니스 로직을 외부에서 격리하여 유지보수와 테스트를 쉽게 하는 것이다.

헥사고날 아키텍처의 구조는 domain, usecase, port, adapter로 나뉜다.
usecase에서 domain과 port를 묶어 비즈니스 로직을 개발한다.(레이어드의 서비스 레이어)
port는 interface로 adapter가 구현하게 되며, usecase에선 adapter가 변해도 상관 없도록 만들어준다.

Port랑 Adapter는 뭐하는건데? 
왜 굳이 나누는지 잘 모르겠음!

이 때 등장하는게 "의존성 역전"이다.

의존성 역전

먼저 의존성을 알아야 한다.
Member를 예시로 들어보자.

이렇게 레이어드 아키텍처를 활용하여 Member를 설계했다.
이 때 만약 MemberRepository에서 수정이 일어나면 어떻게 될까?
분명히 레이어는 다르지만 MemberServie도 함께 수정해야한다.
경우에 따라선 MemberController까지 수정해야 할 수도 있다.
화살표 방향이 의존성의 방향이다.

좀 더 쉽게 말하자면

위 코드에서 PostService는 Util, SchoolRepository, likeRepository, postRepository를 의존하고 있다. 해서 이중 하나라도 바뀌면 PostService는 함께 수정이 일어날 수 있다.

의존성 역전은 이 의존성 자체를 줄여 PostService의 부담을 줄이는 방법이다.

위 사진에서 Controller와 Service의 의존성을 역전해보면 아래와 같은 형태가 된다.

Controller도 Service도 Port를 향하는 형태가 이루어진다.
이제 Port가 변하지 않는 이상 Service와 Controller의 변화는 서로에게 영향을 끼치지 않을 것 이다.

이 의존성 역전이 헥사고날 아키텍처의 핵심이다.
헥사고날 아키텍처를 의존성 역전을 넣어 설명하면 아래와 같다.

레이어드 아키텍처의 레이어 마다 의존성 역전을 하고 Domain을 격리시키는 아키텍처

아직까지 이해가 안간다면 비유를 통해 이해해보자
우리 일상에서 흔히 볼 수 있는 플러그가 있다.

플러그는 전기를 받아 각자의 기능을 한다.
포트가 어디에 어떻게 있든 플러그를 꽂으면 "전기를 준다" 라는 기능은 변치 않는다.
전기를 몇 볼트로 줄지 또한 국내에선 변치 않는다.
그렇기에 우리는 각 기기마다 포트를 따로 찾거나 컨버터를 살 필요가 없는 것이다.

똑같이 의존성 역전은 하위 클래스가 바뀌어도 상위 클래스는 바뀔 때마다 대응하지 않도록 의존성 역전을 통해서 규격을 정해주는 것과 같다.

헥사고날 아키텍처의 장점

• 유연성
• 유지보수성
• 테스트 용이성

1. 유연함
   외부 시스템이나 인프라에 대한 의존도를 낮춰 변화에 편하게 대응할 수 있다.

2. 유지보수성
   책임이 불리돼있어 코드를 이해하고 수정하기 편하다.

3. 테스트 용이성
   비즈니스 로직을 독립적으로 테스트해볼 수 있다.

헥사고날 아키텍처의 단점

• 초반 개발시간의 증가
• 구현 복잡성 증가
• 헥사고날 아키텍처의 학습

1. 초반 개발시간의 증가
   헥사고날 아키텍처는 Port, UseCase, Domain, Adapter 등 초반에 구성해야할 거리가 많은 편이다.

2. 구현 복잡성 증가
   위와 같은 이유로 많은 폴더를 관리하다보니 복잡하다고 느껴질 수 있다.

3. 헥사고날 아키텍처의 학습
   헥사고날 아키텍처는 계층 구조가 아니며 의존성 역전 등을 통해 상호 연결성을 느슨하게 하는데 이 부분이 레이어드 아키텍처를 쓰던 사람들 입장에선 어려울 수 있다.

추천 도서

• https://product.kyobobook.co.kr/detail/S000001766486