DDD Layered Architecture Patterns: Four‑Layer, Five‑Layer, and Hexagonal Approaches

The article begins by revisiting the core concepts of Domain‑Driven Design (DDD), emphasizing the importance of a shared ubiquitous language (UL) and bounded contexts (BC) for clear, unambiguous domain modeling.

It then introduces the notion of layered architecture, describing the principle that each layer should only depend on the layer directly below it, and distinguishes between strict and loose layering.

Three DDD‑oriented layering patterns are presented:

Four‑layer architecture : User Interface, Application, Domain, and Infrastructure layers, with a detailed mapping of responsibilities for each layer.

Five‑layer architecture : Extends the four‑layer model by separating the Context layer (environment) from the Domain layer, resulting in User Interface, Application (Scheduler), Context, Domain, and Infrastructure layers.

Six‑layer architecture : Further splits the Context layer into a lightweight Context layer and a Transaction DSL layer for handling sequences of actions, yielding User Interface, Scheduler, Transaction, Context, Domain, and Infrastructure layers.

The article also discusses the evolution toward the Hexagonal (Ports‑and‑Adapters) architecture, which flattens the hierarchy by making high‑level modules depend on abstractions rather than low‑level details, and shows how DDD tactical patterns such as repositories fit as adapters.

Finally, it summarizes that DDD layered architectures—whether four, five, or six layers—are variants of a bounded‑context, loosely‑coupled design that can be chosen based on the specific needs of a microservice‑oriented system.