An Introduction to Domain-Driven Design Patterns and Practices

Enterprise applications are complex and often focus on technical details like persistence, AJAX, and web services, but without solving business problems they are useless. Domain‑Driven Design (DDD), first described by Eric Evans, redirects attention to the core domain, distinguishing core and supporting sub‑domains.

DDD provides a set of patterns for building domain models. The model is the set of concepts implemented in code, not just diagrams, and code itself is the model. Visualizations such as UML class diagrams or entity‑relationship diagrams are merely views of the model.

Model‑driven design means that changes in the model lead to changes in the code and vice‑versa. While DDD does not force object‑orientation, most mainstream languages are OO, so models are expressed as classes and interfaces.

A ubiquitous language is cultivated between domain experts and developers, using the same terms from the domain model to discuss requirements, which helps expose missing concepts.

Every model exists within a bounded context (BC). Different BCs may interact via published language, open host services, shared kernel, consumer/provider, conformist, or anti‑corruption layer relationships, forming a spectrum of collaboration.

Strategic DDD involves mapping BCs and their dependencies to understand integration risks and opportunities.

Layered architecture places the domain layer at the center, surrounded by application, infrastructure, and presentation layers. However, strict linear dependencies can be problematic, leading many to adopt hexagonal (ports‑and‑adapters) architecture, where the domain sits at the core and interacts with the outside through well‑defined ports.

Key building blocks include:

Entities : mutable, often persisted objects with identity.

Value Objects : immutable objects that encapsulate concepts like Money or SocialSecurityNumber, providing value semantics.

Modules : packages or namespaces that keep the domain model decoupled.

Aggregates and Aggregate Roots : clusters of related entities with a single root that enforces invariants.

Repositories abstract persistence, returning aggregate roots and supporting multiple implementations (e.g., Hibernate, in‑memory). Factories create aggregates, often using interfaces to avoid circular dependencies.

Domain services contain business logic that does not naturally belong to an entity, while infrastructure services implement technical concerns such as email or PDF generation. Application services orchestrate use cases, invoking domain services, repositories, and infrastructure services, and mediate between the presentation layer and the domain.

Overall, DDD provides a comprehensive set of patterns to align software design with business requirements, reducing complexity and improving maintainability.

Figure 1: Model vs Views of the Model

Figure 2: Bounded Context Relationship Spectrum

Figure 3: Layered Architecture

Figure 4: Hexagonal Architecture

Money m1 = new Money("GBP", 10);
Money m2 = new Money("GBP", 20);
Money m3 = m1.add(m2);

Figure 5: Example of immutable Value Object usage.