Choosing the Right DDD Layered Architecture: 4‑, 5‑, and Hexagonal Patterns Explained

Introduction

The article begins with a quick recap of Domain‑Driven Design (DDD) and the purpose of layered architecture before diving into concrete patterns.

DDD Basics

DDD (Domain‑Driven Design) is a software development methodology that helps create high‑quality domain models. A ubiquitous language (UL) shared by the whole team is a cornerstone, and bounded contexts (BC) define explicit boundaries where domain models live. Context maps integrate multiple BCs.

Layered Architecture Benefits

Layered architecture promotes loose coupling between layers, making each layer easier to design, maintain, and evolve. Changes in one layer affect only adjacent layers, reducing risk. Martin Fowler lists benefits such as focused development, easy replacement of implementations, reduced inter‑layer dependencies, standardization, and logical reuse.

Pattern 1: Four‑Layer Architecture

The classic four‑layer model consists of:

User Interface – handles UI or external requests.

Application – coordinates tasks, manages processes, threads, and coroutines, but contains no business rules.

Domain – core business logic and domain model.

Infrastructure – provides technical capabilities such as persistence, messaging, and third‑party libraries.

In practice the author refines each layer’s responsibilities, e.g., UI for RESTful handling, Application for scheduling, Domain for object and role modeling, Infrastructure for platform services.

Pattern 2: Five‑Layer Architecture (DCI)

DCI (Data‑Context‑Interaction) extends DDD by separating data, context, and interaction:

Data – defines domain concepts and relationships.

Context – thin, stateless layer that binds domain objects to roles for a use case.

Interaction – models role behavior and connects context to domain objects.

When mapped to DDD, the Domain layer becomes a combination of Data and Interaction, while the Context layer moves up to become its own layer. The author’s practical five‑layer definition mirrors this mapping.

Pattern 3: Six‑Layer Architecture for Control‑Intensive Systems

For systems with many control‑plane messages, the author splits the Context layer into two layers and adds a Transaction layer:

User Interface – handles RESTful requests and config parsing.

Scheduler – manages processes, threads, and coroutines.

Transaction – groups a sequence of messages into a transactional unit, often expressed with a Transaction DSL.

Context – processes individual actions, casting domain objects to roles.

Domain – defines models and explicit role modeling.

Infrastructure – provides platform, framework, persistence, messaging, and utility algorithms.

Pattern 4: Hexagonal (Ports & Adapters) Architecture

Applying the Dependency Inversion Principle (DIP) flattens the traditional layered stack, leading to the hexagonal architecture (also called Ports & Adapters). Different clients interact with the system through equal ports, each with an adapter that translates input or output. The application core uses domain models, while adapters implement persistence, messaging, or external protocol handling.

Evolution of Hexagonal Architecture

Since its introduction, hexagonal architecture has inspired several variants: the Onion Architecture (Jeffrey Palermo, 2008), Clean Architecture (Robert C. Martin, 2012), and Life Preserver design (Russ Miles, 2013).

Conclusion

By revisiting DDD fundamentals and detailing three classic layered patterns—four‑layer, five‑layer (DCI), and hexagonal—the article equips readers with the knowledge to choose an appropriate architecture for their microservice projects, aiming for clear structure and maintainable software.