Domain-Driven Hexagonal Architecture Through Code Examples

The Zigzag PDP service has been operating on a Domain-Driven Hexagonal Architecture structure since 2024, combining data pulled from about 20+ microservices into a single page. Since it must not simply display product information but receive and process information from multiple sources in real time, the Aggregate model and Port / Adapter separation became key.

The core flow is Controller → Input Port → Domain → Output Port. PdpController only serves as the entry point, while PdpPageAdapter connects PdpAggUseCase, PdpPageUseCase, and LineMarginUseCase to build the page. On the domain side, PdpAggService gathers sub-aggregates such as catalog, shop, price, review, and content in parallel to create PdpAgg.

In the content aggregate example, ContentAggService, which fetches banner information, only depends on PdpBannerQueryPort. The actual data source may change—Redis, an external API, RDB, local cache—but since the domain service only looks at the interface, the business logic remains unchanged even if the external storage or call method changes.

The advantages of this structure can be summarized in three points.

• Business logic protection: Even if a local cache is added because Redis lookups are excessive, or an RDB is attached instead of an external API, the domain code barely changes.
• Ease of extension: When adding badges or notices in addition to banners, you only need to add a new Output Port and aggregate combination.
• Testability: Mocking is easy at the port level, making it good for verifying domain logic in isolation.

The caching strategy was also designed to be changeable at the Domain level rather than the DTO. With ContentAggQueryPort and ContentAggCommandPort in place, if a cache exists it is returned as-is, and if not, data is gathered from sub-ports to create ContentAgg before being stored. Thanks to this, even if the cache location or storage layer changes, the domain assembly method stays the same.

On the input port side as well, to accommodate requirements where page types differ, the response is handled by adding new page creation logic centered on the interface. Ultimately, the point of this architecture is that the domain only depends on interfaces, while the actual technology choices and priorities are the responsibility of the Adapter.