헥사고날 아키텍처란?

 

 

 

 

 

 

 

 

핵사고날 아키텍처의 핵심 개념

1. 헥사고날 아키텍처는 전통 방식인 계층형 아키텍처의 단점을 보완하기위해 설계되었다.
2. 어댑터와 포트를 중심으로 구성되어 포트와 어댑터 아키텍처로 불리기도 한다.
3. 비즈니스 로직을 외부로부터 격리시켜  외부 시스템과 의존성을 최소화한다.
   1. 핵심 비즈니스 로직은 중앙의 도메인 영역에 위치하며, 입출력을 처리하는 포트와 어댑터를 통해 외부와 소통한다.
   2. 도메인 로직과 인프라 스트럭처 계층을 명확히 분리함으로써 변경 사항이 도메인 로직에 미치는 영향을 줄일 수 있다.
   3. 해당 구조는 유지보수를 용이하게하여 시스템의 다양한 부분을 독립적으로 개발하고 테스트할 수 있는 환경을 제공한다.
   4. 헥사고날 아키텍처는 도메인 중심 설계와 밀접하게 연관되어있어 비즈니스 로직의 중심성을 강조한다.

 

 

계층형 아키텍처의 문제점

1. 데이터베이스, 영속성에 대한 의존성
   1. 도메인 계층이 데이터베이스에 의존하게 되어 데이터베이스에 변화가 일어나면 도메인 계층에도 변화가 생긴다.
      서비스 계층에서도 영속성 모델을 도메인 모델처럼 사용하게 된다.
   2. 즉시로딩, 지연로딩, 트랜잭션 등을 고려해야하고 영속성에 대한 의존이 프로젝트 전체적으로 퍼지게 되어 변경에 취약해진다.
2. 아키텍처 경계를 강제할 수 없다.
   1. 계층형 아키텍처에서는 상위 계층에 있는 컴포넌트에 접근할 목적으로 해당 컴포넌트를 하위 계층으로 내릴 수 있다.
   2. 이러한 행위가 반복되면 점점 경계가 모호해지고 허물어지게 된다. 
3. 계층을 스킵 할 수 있다.
   1. 계층을 건너뛰는 것이 가능하다.
   2. 구현이 간단한 경우 Controller에서 바로 도메인을 참조하는 등의 로직을 작성할 수 있다. 이 경우의 문제는 기능 확장이 어렵고, 테스트가 복잡해진다. 
4. 유스케이스를 숨긴다.
   1. 개발자는 유스케이스를 어느 계층에나 자유롭게 생성할 수 있다.
   2. 개발자가 유스케이스의 존재 여부를 파악하기 어려워서 동일한 로직을 다른 위치에 새롭게 구현하여 코드를 더럽히게 된다. 
5. 서비스의 크기를 강제할 수 없다.
   1. 계층형 구조에서는 서비스의 크기를 강제하지않는다. 수십개의 서비스 로직을 한곳에 전부 작성할 수도 있다.
   2. 이 경우에 서비스가 너무 많은 의존을 가져 수많은 웹 계층이 해당 서비스를 의존하게 된다. 결국 서비스를 테스트하기 어려워지고 작업해야할 유스케이스를 찾기도 힘들어진다.

 

 

 

 

 

헥사고날 아키텍처와 도메인 주도 설계(DDD)와 연관관계

1. 도메인 주도 설계는 소프트웨어 개발에서 비즈니스 도메인의 복잡성을 관리하는 방법론이다.
2. 헥사고날 아키텍처와 DDD는 서로 보완적인 관계에 있다.
3. DDD는 도메인 모델 중심으로 시스템을 설계하고, 헥사고날 아키텍처는 이러한 도메인 모델을 효과적으로 구현할 수 있는 구조를 제공한다.
4. DDD 구현의 핵심 3가지 Layer
   1. Application Layer: 주로 도메인과 Repository를 바탕으로 실제 서비스(API)를 제공하는 계층
   2. Domain Model Layer: Entity를 활용해 도메인 로직(비즈니스 로직)이 수행되는 계층
   3. Infrastructure Layer: 외부와 통신(RDBMS, Redis, HttpClient, ...)을 담당하는 계층

 

주요 컴포넌트

 

Adapter

• 포트를 통해 인프라와 실제로 연결하는 부분을 담당하는 구현체를 의미
• 인프라나 web과 같은 저수준 layer들이 도메인 로직에 접근할 수 있는 포트를 사용

이름	설명	예시
Driving Adapter  = Primary Adapter	사용자의 요청을 받아들일 때 사용되는 Adapter	AWS Lambda의 Handler WebApplication의 Controller(UI) adapter, application을 동작시키는(Driving) 역할. 인바운드 포트 사용 사용자 요청 → Controller → [Input Port] → Application
Driven Adapter  = Secondary Adapter	도메인 모델의 처리에 사용되는 Adapter	MessageQueue Persistence Adapter application에 의해 동작되는(Driven) 역할. 주로 인프라와 연결되는 역할. 아웃바운드 포트 사용 Application → [Output Port] → DB/외부API

 

 

 

Port

• 서비스(또는 usecase)에 어댑터에 대한 명세만을 제공하는 계층
• 단순히 인터페이스 정의만 존재하며, DI를 위해 사용된다.
• Port는 application 입장에서 consumer, 또는 application에서 나가거나/들어오는 end point라고 보면 됨.
• 포트는 내부 비즈니스 영역을 외부 영역에 노출한 API이고 인바운드(Inbound)/아웃바운드(Outbound) 포트로 구분
  • 인바운드 포트 - 내부 영역 사용을 위해 노출된 API
  • 아웃바운드 포트 - 내부 영역이 외부 영역을 사용하기 위한 API

 

Application Service(usecase)

• 어댑터를 주입 받아 도메인 모델과 어댑터를 적절히 오케스트레이션하는 계층을 의미

 

Domain Model

• DDD의 도메인 모델과 동일한 개념을 지닌 계층
  • 비즈니스 로직이라 부르는 엔티티에 대한 변경은 모두 해당 계층에서만 실행된다.
  • 원칙적으로는 어떠한 의존성도 없어야 하지만 Entity를 만들 때 Database에 적재되어 있는 데이터를 참고해야하는 경우와 같은 상황에서는 Port를 이용해 Adapter를 주입받아서 사용할 수 있다는 예외사항이 존재하기도 한다.

 

 

헥사고날 아키텍처 장단점

장점

• 유연성 : 외부 시스템이나 인프라와의 의존성이 낮아 구성요소를 쉽게 교체하거나 업데이트가 가능
  • 다형성으로 인해 DIP 원칙 준수
• 테스트 용이성 : 비즈니스 로직을 독립적으로 테스트할 수 있음
• 유지보수성 : 책임이 분리되어 있어 코드의 이해와 수정이 용이

 

단점

• 구현 복잡성 : 포트와 어댑터를 구성하고 관리하는데 복잡도 증대
• 오버헤드 발생: 초기 개발 시간 증가, 도메인 모델의 표현 사이를 매핑할 객체 필요
  • ORM 프레임워크는 DB 구조 및 객체 필드와 칼럼의 매핑을 서술한 메타데이터를 담고 있는 엔티티 클래스 필요. 
  • 도메인 계층은 영속성 계층을 모르기 때문에, 두 계층에서 각각 엔티티를 만들어주어야 하고 도메인 계층과 영속성 계층이 데이터를 주고 받을 때, 두엔티티를 서로 매핑하는 과정이 발생함.