코드 사례로 보는 Domain-Driven Hexagonal Architecture

지그재그 PDP 서비스는 2024년부터 Domain-Driven Hexagonal Architecture 구조로 운영되고 있으며, 약 20여 개의 microservice에서 가져오는 데이터를 하나의 페이지로 조합한다. 단순히 상품 정보를 보여주는 것이 아니라, 여러 소스의 정보를 실시간으로 받아 가공해 노출해야 해서 Aggregate 모델과 Port / Adapter 분리가 핵심이 됐다.

핵심 흐름은 Controller → Input Port → Domain → Output Port다. PdpController는 진입점 역할만 하고, PdpPageAdapter가 PdpAggUseCase, PdpPageUseCase, LineMarginUseCase를 연결해 페이지를 만든다. 도메인 쪽에서는 PdpAggService가 catalog, shop, price, review, content 같은 하위 aggregate를 병렬로 모아 PdpAgg를 생성한다.

컨텐츠 aggregate 예시에서는 배너 정보를 가져오는 ContentAggService가 PdpBannerQueryPort만 의존한다. 실제 데이터 소스는 Redis, external API, RDB, 로컬 캐시처럼 바뀔 수 있지만, 도메인 서비스는 인터페이스만 바라보므로 외부 저장소나 호출 방식이 바뀌어도 비즈니스 로직은 그대로 유지된다.

이 구조의 장점은 세 가지로 정리된다.

• 비즈니스 로직 보호: Redis 조회가 과도하면 로컬 캐시를 추가하거나, 외부 API 대신 RDB를 붙여도 도메인 코드는 거의 안 바뀐다.
• 확장 용이성: 배너에 더해 badge, notice를 추가할 때도 새로운 Output Port와 aggregate 조합만 더하면 된다.
• 테스트 용이성: 포트 단위로 mocking이 쉬워서 도메인 로직을 분리된 상태로 검증하기 좋다.

캐시 전략도 DTO가 아니라 Domain 레벨에서 바꿀 수 있도록 설계했다. ContentAggQueryPort와 ContentAggCommandPort를 두고, 캐시가 있으면 그대로 반환하고 없으면 하위 포트에서 데이터를 모아 ContentAgg를 만든 뒤 저장한다. 덕분에 캐시 위치나 저장 계층이 바뀌어도 도메인 조립 방식은 유지된다.

입력 포트 쪽에서도 페이지 타입이 달라지는 요구사항을 수용하기 위해, 인터페이스를 중심으로 새 페이지 생성 로직을 추가하는 식으로 대응한다. 결국 이 아키텍처의 요지는, 도메인은 인터페이스에만 의존하고, 실제 기술 선택과 우선순위는 Adapter가 책임지는 것이다.