헥사고날 아키텍처? (Hexagonal Architecture)

*유튜브 강의 영상을 정리해보았습니다* 

CS세계의 방향성

- 비지니스 로직에 집중한다.

- 인프라를 추상화해서 해결(e.g. 서버리스)

- 코드레벨에서도 비지니스 로직에만 집중

출처: https://medium.com/codex/clean-architecture-for-dummies-df6561d42c94

● 좀 더 나은 상태의 경우 추상화된 레이어를 통해 의존성을 역전해주면 인프라를 수정해도 비지니스로직의 수정을 하지 않아도 된다.

 

헥사고날 아키텍처

헥사고날 아키텍처(육각형 아키텍처)는 알레스테어 콕번이 만든 용어로 클린 아키텍처를 일반화한 구조 중 하나라고 한다.

전통적인 계층형 아키텍처의 단점을 보완하기 위해 생겼다.

 

클린아키텍쳐

출처: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

● 비지니스 로직(엔티티)과 인프라에 대한 디펜던시를 없애는 컴포넌트 설계방식

● 유즈케이스 추상화 레이어를 통해 전체적인 흐름을 제어함

● 의존성은 외부에서 내부로만 존재함

 

헥사고날 아키텍쳐

출처: https://medium.com/@hello-every-one/hexagonal-architecture-3729e9a9200b

     ● 클린아키텍쳐에 비해 단순

     ● 마찬가지로 의존성은 외부에서 내부로만 존재 

    (육각형 아키텍처라는 이름을 가졌지만 사실 4개의 면을 나타내기 위해 육각형을 사용했다고 함)

 

주요 컴포넌트

1. Adapters/Ports

    - Adapters

        - 사용자의 요청을 받아들일 때 사용되는 driving adapter 또는 primary adapter

        - 도메인 모델의 처리에 사용되는 driven adapter 또는 secondary adapter

   - Ports

       - 인터페이스 정의만 존재

       -  DI(Dependency Inversion)을 위한 추상화

2. Application Services

   - 어댑터를 주입받아서 도메인 모델과 어댑터, 포트를 적절히 조정(오케스테이션)

   - 비지니스 모델 안에 있는 비지니스 로직이 실행되기 위해 필요한 내용들을 중간에서 담당해주는 부분

   - 최대한 dumb

3. Domain Model

   - DDD의 도메인 모델

       - 모든 엔티티에 대한 변경은 여기에서만 실행 → 일반적으로 비지니스 로직이라고 함

  - 어떠한 의존성도 없어야 함 (외부에서 내부로만 의존성이 있으니까!)

       - But, 예외 상황 존재

         → 레포지토리의 경우 포트를 이용해 어댑터 주입받아 사용 

         (DB 데이터 기준으로 엔티티를 만들어야하는 경우 도메인 모델에서 DB, port를 통해 가져와 만듦)

 

 

그렇다면 헥사고날/클린 아키텍쳐를 "왜" 사용하느냐?

  ● 명확한 관심사의 분리

     - 어댑터, 포트, 서비스는 비지니스 로직이 하나도 없음

     - 외부 연결에 문제가 생겼다면 → 어댑터

     - 인터페이스는 → 포트

     - 처리중간에 EvenBridge에 이벤트를 보내거나 트레이스 로그를 심고 싶다면 → 서비스

     - 비지니스 로직이 제대로 동작하지 않으면 → 도메인 모델

 

 ● 쉬운 테스트

     - 자기 역할만 Port기반 모킹을 통해 테스트

     - 비지니스 로직은 의존성이 없기 때문에 모킹이 거의 없고 순수하게 비지니스 로직을 테스트할 수 있다.

 Mocking: 외부 서비스에 의존하지 않고 독립적으로 실행 가능한 단위 테스트를 작성하기 위해 사용되는 테스팅 기법

 

해서 폴더 구조는 다음과 같은 느낌!

 

 

 

*참고 자료*

헥사고날(Hexagonal) 아키텍처란 무엇인가?!