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

Introduction

Before discussing DDD layered architecture patterns, we first review the related concepts of Domain‑Driven Design (DDD) and layered architecture.

DDD

Domain‑Driven Design (DDD) is a software development methodology that helps create high‑quality domain models. The ubiquitous language (UL) is a shared language for the whole team, and bounded contexts (BC) define clear boundaries for concepts. A business domain is divided into several BCs that are integrated via a Context Map, and the domain model lives inside each BC.

In microservice practice, DDD concepts are widely used: establish UL first, keep each microservice within a single BC, avoid overly small microservices that would cause distributed transaction complexity, align microservice boundaries with BC boundaries, use Context Maps for integration, and prefer domain events for loose coupling.

Layered Architecture

An important principle of layered architecture is that a layer may only depend on the layer directly below it. Strict layering allows coupling only to the immediate lower layer, while loose layering permits coupling to any lower layer.

The benefits of layered architecture include isolated design focus per layer, easier maintenance, and reduced impact of changes. However, it can introduce performance overhead and cascade modifications, which can be mitigated by caching and dependency inversion.

Pattern One: Four‑Layer Architecture

Eric Evans described a traditional four‑layer architecture consisting of:

User Interface (UI) – the presentation layer that displays information and interprets commands.

Application – defines tasks, orchestrates domain objects, and coordinates work without containing business rules.

Domain – expresses business concepts, state, and rules; the core of the software.

Infrastructure – provides technical capabilities such as persistence, messaging, and UI rendering.

In practice, the author maps RESTful handling and configuration parsing to the UI layer, process management to the Application layer, domain object lifecycle and services to the Domain layer, and platform/framework utilities to the Infrastructure layer.

Pattern Two: Five‑Layer Architecture (DCI)

The DCI (Data‑Context‑Interaction) architecture adds a thin Context layer that binds objects to roles for a use case. The three DCI layers are:

Data – defines domain concepts and their relationships.

Context – a lightweight, often stateless layer that selects appropriate roles and drives interaction.

Interaction – models behavior through roles, separating stable domain models from volatile business logic.

Applying DCI to DDD flattens the original Domain layer into Data and Interaction, while the Context layer moves up, resulting in a five‑layer stack: UI, Application (Scheduler), Context, Domain (Data + Interaction), and Infrastructure.

Pattern Three: Hexagonal (Ports & Adapters) Architecture

Based on the Dependency Inversion Principle, the hexagonal architecture (also called Ports & Adapters) treats the application core as independent of external agents. Different adapters implement input ports (e.g., HTTP, SOAP, AMQP) and output ports (e.g., databases, message brokers). The core uses domain models and repositories, while adapters handle technical details.

The hexagonal style can evolve into Onion Architecture, Clean Architecture, and Life Preserver designs.

Summary

The article revisits DDD and layered architecture fundamentals, then details three common DDD layered patterns—four‑layer, five‑layer (DCI), and hexagonal—providing practical insights so readers can choose the most suitable architecture for microservice development, delivering clear and maintainable software.