Mastering Domain-Driven Design: Core Concepts, Patterns, and Practical Code Examples

About Domain‑Driven Design

This article draws on Eric Evans' book Domain‑Driven Design and Jimmy Nilsson's Applying DDD and Patterns with C# .NET to present the core concepts, techniques, and patterns of DDD. It emphasizes that DDD methods are tools for design, not rigid rules, and that the goal is to make pragmatic decisions that improve communication and model clarity.

Representative Model

The primary purpose of DDD is to create expressive models that all stakeholders can understand. Because non‑technical participants also use these models, they can be expressed in UML sketches, source code, or a domain‑specific language.

Using a Domain Language

When a person registers for a course, the system sends a registration invitation that can later be accepted or cancelled. The example illustrates how a simple domain language can describe the process.

Using Code

class Person { }

public Registration bookCourse(Course c) { ... }

abstract class Registration { public abstract void accept(); public abstract void cancel(); }

class ReservedRegistration extends Registration { ... }

class AcceptedRegistration extends Registration { ... }

interface CourseRepository { List<Course> find(...); }

Using UML Sketches

Ubiquitous Language

Consistently using a shared language is essential for conveying the intrinsic meaning of domain concepts. The article warns that technical jargon can obscure important ideas and that the language should reflect the high‑level intent of the model rather than implementation details.

Strategic Design: Context Mapping

Large models are divided into bounded contexts that interact through explicit context maps. The article describes several mapping patterns:

Shared Kernel : a subset of the domain shared between teams, requiring strong collaboration.

Customer/Supplier (Consumer/Producer) Teams : clarifies upstream and downstream relationships.

Conformist : downstream teams conform to upstream models to avoid friction.

Anti‑Corruption Layer : isolates contexts by translating between models.

Separate Ways : splits contexts when integration cost outweighs benefits.

Tactical Design: Building the Model

The article outlines the most common DDD building blocks and their responsibilities.

Entity

Entities have a global identity that never changes, even if their attributes vary. Example: a Client entity whose Address may change but the client ID remains constant.

Value Object

Value objects are immutable, have no identity, and are ideal for encapsulating complex calculations. Example: an Address value object assigned to a Client when the address changes.

Aggregate

Aggregates define consistency boundaries. An aggregate has a root entity that controls access to internal objects. Rules for aggregates include a global identity for the root, invariants enforced by the root, and external references only to the root.

Factory & Repository

Factories create new aggregates while repositories retrieve and persist them, often delegating to an ORM. Both belong to the domain layer.

Specification & Strategy Patterns

Specifications encapsulate business rules (e.g., ProjectIsOverdueSpecification) allowing flexible composition. The strategy pattern separates algorithms (e.g., success criteria) from the domain object, enabling interchangeable policies.

interface ProjectSpecification { boolean isSatisfiedBy(Project p); }
class ProjectIsOverdueSpecification implements ProjectSpecification { ... }

interface ProjectSuccessPolicy { Boolean isSuccessful(Project p); }
class SuccessByTime implements ProjectSuccessPolicy { ... }
class SuccessByBudget implements ProjectSuccessPolicy { ... }

Domain‑Driven Architecture

When the focus is on a behavior‑rich domain model, the surrounding architecture must keep the model independent of infrastructure concerns. A typical layered architecture separates UI, Application, Domain, and Infrastructure layers, enforcing directionality of dependencies.

The UI layer (often MVC) interacts with the Application layer, which coordinates use‑cases. The Domain layer contains entities, value objects, aggregates, services, factories, and repositories. The Infrastructure layer provides technical implementations such as persistence and messaging, but domain code should depend only on abstractions defined in the Domain layer.

Conclusion

Domain‑Driven Design provides a set of strategic and tactical tools for building expressive, maintainable software models. By using a ubiquitous language, clearly bounded contexts, and well‑defined building blocks (entities, value objects, aggregates, factories, repositories, specifications, and patterns), teams can align technical design with business intent and keep the domain model resilient to infrastructure changes.