Unlocking Domain-Driven Design: Core Concepts and Strategic Patterns

1. Building Blocks

Constructing Blocks are the most basic elements in domain design.

1.1 Layered Architecture

Layering is a common approach, also seen in network models. Benefits include focusing on each layer’s responsibilities and improving collaboration.

Basic principle: elements in a layer may only depend on elements within the same layer or lower layers. If an upper layer must call a lower one, use appropriate patterns such as observer or callbacks.

Presentation Layer (or UI Layer): displays information, e.g., web controllers.

Application Layer: coordinates domain objects, e.g., services supporting controllers.

Domain Layer (or Model Layer): expresses business concepts, state, and rules.

Infrastructure Layer: provides generic technical capabilities, e.g., database access.

1.2 Associations

Models are subsets of real‑world models; not every detail is needed. Three ways to reduce relationship complexity:

Define a directional traversal to simplify many‑to‑many into one‑to‑many.

Add a qualifier to limit multiplicity, e.g., only one principal at a time.

Eliminate unnecessary associations – “less is more”.

1.3 Entity

An entity is an object defined primarily by its identifier, maintaining continuity throughout its lifecycle, e.g., an order with an order ID.

1.4 Value Object

A value object describes an aspect of the domain without its own identity; equality is based on attribute values, e.g., an RGB color.

Often passed as parameters, usually temporary.

Design choices: copy, share, or keep immutable.

Enables caching and sharing for performance.

1.5 Service

Domain‑layer services encapsulate operations that don’t naturally belong to entities or value objects. They are stateless, defined by interfaces derived from other domain elements.

Operations are stateless functions coordinating multiple objects.

Service interfaces may appear in other layers based on responsibilities.

1.6 Aggregate

An aggregate groups related objects under a root and a boundary; external objects may only reference the root.

1.7 Factory

A factory handles creation of complex objects and aggregates.

1.8 Repository

A repository provides data access capabilities for objects that need direct persistence, encapsulating storage logic.

1.9 Specification

A specification is a predicate‑style value object used to determine whether an object satisfies certain criteria, useful for rules that don’t fit entities or value objects.

2. Supple Design

2.1 Intention‑Revealing Interfaces

Names of classes and operations should describe their effect and purpose.

2.2 Side‑Effect‑Free Function

Encapsulate logic in functions that avoid noticeable side effects; isolate commands that cause state changes.

2.3 Assertion

Use assertions or unit tests to declare correct program state at specific moments.

2.4 Conceptual Contour

Maintain domain consistency by decomposing design elements into cohesive units.

2.5 Standalone Class

A class that can be understood and tested without referencing other objects (aside from basic libraries), reducing coupling.

2.6 Closure of Operation

Provide a high‑level interface without introducing dependencies on other concepts; return types may match parameter types.

3. Strategic Design

3.1 Bounded Context

A bounded context defines the limits of a specific model, clarifying what must stay consistent and what can be developed independently.

3.2 Continuous Integration

Frequent merging of work to keep it consistent.

3.3 Context Map

A visual representation of bounded contexts and their relationships, highlighting communication points and shared elements.

3.4 Shared Kernel

A set of core domain concepts or common sub‑domains shared across contexts.

3.5 Customer/Supplier

Upstream/downstream relationship; upstream teams need automated test suites, and downstream teams negotiate to balance needs.

3.6 Conformist

One‑sided follow‑the‑leader mode where the downstream team strictly adheres to the upstream model.

3.7 Anticorruption Layer

Isolation layer using façade or adapter patterns to protect the system from external changes.

3.8 Separate Way

Declare a bounded context completely independent of others, allowing simple, dedicated solutions.

3.9 Open Host Service

Expose a subsystem for other systems to access.

3.10 Published Language

Use a well‑documented shared language as a communication medium, converting other information to it when necessary.

4. Distillation

4.1 Core Domain

The most critical part of the model, representing the primary business purpose.

4.2 Generic Subdomain

Identify cohesive sub‑domains unrelated to the project’s intent and extract them as generic models.

4.3 Domain Vision Statement

A document focusing on the essence of the domain model and its value to the business.

4.4 Highlight Core

Write concise documentation describing the core domain and its main interactions, marking the core explicitly.

4.5 Cohesive Mechanism

Separate cohesive parts into a lightweight framework and expose functionality via intention‑revealing interfaces.

4.6 Segregated Core

Extract core concepts from supporting elements, enhancing core cohesion while moving generic elements elsewhere.

4.7 Abstract Core

Identify the most fundamental concepts, place them in an abstract model (interfaces or abstract classes), and keep implementations in sub‑domain modules to reduce inter‑module complexity.

5. Large‑Scale Structure

5.1 Evolving Order

Allow the large‑scale structure to evolve alongside the application, potentially transforming into a different architectural style.

5.2 System Metaphor

Use a concrete analogy that matches the team’s mental model to guide thinking, e.g., comparing a network firewall to a building’s fire wall.

5.3 Responsibility Layer

Layer concepts around primary responsibilities, combining layering with responsibility‑driven design.

5.4 Knowledge Level

A set of objects describing the behavior another set of objects should have; useful for exposing control over part of the model while satisfying broader rules.

5.5 Pluggable Component Framework

Derive an abstract core from interfaces and interactions, then build a framework that allows interchangeable implementations of those interfaces.