Search

헥사고날 아키텍쳐

Tags
java
hexagonal
architecture
Created
2024/04/20 14:24
Created time
2024/04/20 05:24
category
java

개요

다른 기업에 취업을 준비 중인 멘티가 헥사고날 아키텍쳐를 적용해보려는 시도가 있었고, 이와 관련하여 내용을 간단하게 정리 시도
** 구체적으로 헥사고날 아키텍쳐의 개념, 가치, 그리고 지향점에 대해 알고 싶다면 더 잘 작성된 글들이 많으니 그걸 찾아보는 거로…

헥사고날 아키텍쳐

지향점

헥사고날 아키텍쳐는 외부의 요인으로 핵심이 되는 비즈니스 로직이 방해받지 않겠다는 결연한 의지를 가진 구조
또한 아래에 기재된 구성 요소를 읽어보면 헥사고날 아키텍쳐가 의존성에 영향을 받지 않기 위한 구조이기 때문에 유닛 테스트와 밀접한 구조임을 알 수 있음

구성 요소

비즈니스 로직을 중심에 두고, 외부에서 들어오는 요인 (Adapter In), 외부에 의존하는 요인 (Adapter Out)이 존재
Web 프레임워크를 기준으로 보면…
Adapter In에 해당하는 부분들은 Controller에 대입하여 생각하면 편함
→ Rest API Controller
→ gRPC Controller
Adapter Out에 해당하는 부분들은 시스템 내부에서 사용하는 의존성 플랫폼들을 지칭
→ Database
→ Message Queue

비교

어플리케이션의 흐름은 Presentation → Application → Domain → Infrastructure로 이뤄지는데, DDD의 레이어드 아키텍쳐에서는 이런 흐름이 Controller → Service → Repository와 같음
대체로 많이 사용하는 레이어드 아키텍쳐와 비교한다면, 헥사고날 아키텍쳐는 Adapter In → Application → Domain → Adapter Out과 같은 흐름을 가짐

디렉토리 구조

구조는 모듈을 어떻게 나누는지, 구성 요소들을 어떻게 배치하느냐에 따라 달라질 수 있고, 다른 글들을 참고 했을 때도 대체로 디렉토리 구조가 다른 것으로 보아 지향점만 잘 녹아든 디렉토리 구조면 되는 것으로 판단
. |_______ adapter | |_______ input | | |_______ web | | |_______ (controllers) | |_______ output | |_______ persistence | |_______ (MQ : Kafka / Rabbit) | |_______ (RDB : MySQL / PSQL) | |_______ (NoSQL : Mongo / Redis) | |_______ application | |_______ port | | |_______ in | | | |_______ (usecases : 서비스 인터페이스) | | |_______ out | | |_______ (outport) | |_______ service (usecaseimple: 서비스 구현체) | |_______ domain
Java
복사
application.port는 인터페이스들을 정의
application.port.in은 서비스의 인터페이스를 정의 (InPort)
application.port.out은 플랫폼 의존성의 인터페이스를 정의 (OutPort)
application.service는 application.port.in의 인터페이스를 이용하여 서비스 구현체를 생성 (impl)
domain은 비즈니스 로직에서 사용하는 도메인 객체를 정의 및 구현
adapter.input은 controller 관련 요청을 받는 경로의 정의
adapter.ouput은 application.port.out의 인터페이스를 이용하여 플랫폼 의존성의 구현체를 생성 (impl)

결론

헥사고날 아키텍쳐의 구조와 그림을 보면 알다시피, 어떤 코드가 있다면 해당 코드가 외부에 종속되는지 내부에 종속되는지를 엄격히 따짐
외부/내부의 위치 여부를 구조 상에서 엄격히 구분하고, 외부 의존성을 최대한 낮춰서 도메인과 관련된 비즈니스 로직을 사수하는데 있다는 것을 알 수 있음
아무래도 외부 의존성이 낮다보니 자체적으로 정의한 의존성을 주입하기도 편리하여 테스트에 용이하다는 것을 느낄 수 있었음
특히 주의할 점으로는 링크드인에서 Toby의 말에 따르면 헥사고날 적용할 때 헥사고날임을 명확히 인지할 수 있도록 (네이밍이 좀 헷갈려서…) 네이밍을 엄격히 지키자는 얘기가 있었음
외부 의존성이 강하고 흔들릴 여지가 큰 프로젝트라면, 헥사고날이큰 가치가 있을 것으로 판단

사례