software-architecture-design

Domain-Driven Design

7 min read

Domain-Driven Design

An approach to software development for complex problem domains in which the software model is built around a deep understanding of the business domain, expressed in a shared language between developers and domain experts.

Coined and formalized by Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). Fowler describes it as “an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain.”

Problem

In complex business domains, software built without deep domain understanding diverges from the business it serves. Logic scattered across services, anemic data models, and translation layers between “tech speak” and “business speak” lead to systems that are hard to evolve, riddled with implicit business rules, and opaque to the domain experts who understand the business. Teams lack shared vocabulary, leading to misunderstandings and inconsistent models across system components.

Solution

Center software design on a rigorous model of the domain (the subject area the software addresses). Build that model collaboratively with domain experts using a Ubiquitous Language — a shared vocabulary embedded directly in conversation, code, tests, and documentation. The ubiquitous language evolves throughout the product lifecycle rather than being finalized upfront.

DDD divides into Strategic Design (large-scale system structure) and Tactical Design (fine-grained building blocks).

Key Components / Structure

Strategic Design

Strategic Design represents DDD’s most innovative contribution — organizing large domains into bounded contexts. As Fowler notes, before DDD’s strategic patterns, no one had tackled the problem of managing large-scale domain model decomposition in a compelling way.

ConceptMeaning
DomainThe subject area the software addresses (e.g., hospital management, e-commerce)
SubdomainA cohesive part of the domain — Core (competitive differentiator), Supporting (necessary but not differentiating), Generic (commodity, off-the-shelf)
Bounded ContextAn explicit boundary within which a particular domain model applies and the ubiquitous language is consistent. Breaks large domains into manageable parts with clear terminology
Ubiquitous LanguageShared vocabulary between developers and domain experts, used consistently in code and conversation
Context MapDiagram showing the relationships and integration patterns between Bounded Contexts
Anti-Corruption Layer (ACL)Translation buffer protecting the core domain model from external or legacy systems with different models
Shared KernelA deliberately shared subset of the domain model between two bounded contexts

Tactical Design (building blocks)

Building BlockRole
EntityAn object with a unique identity that persists over time; defined by its identity, not its attributes (e.g., Order, User)
Value ObjectAn immutable object defined entirely by its attributes, with no identity (e.g., Money, Address, Location)
AggregateA cluster of Entities and Value Objects with a single root (Aggregate Root) that enforces all invariants; processed as a unit
Aggregate RootThe entry point for an Aggregate; external objects may only reference the root, not internal entities
Domain EventA record of something significant that happened in the domain (feeds Event Sourcing / CQRS)
RepositoryAbstraction for persisting and retrieving Aggregates — see Repository Pattern
Domain ServiceStateless operations that don’t naturally belong to a single Entity or Value Object
Application ServiceOrchestrates use cases by coordinating domain objects and infrastructure; the boundary between domain and delivery mechanisms
FactoryEncapsulates complex object creation logic for Aggregates or Entities

When to Use

  • Complex core business domains where modeling the problem correctly is the dominant challenge.
  • Domains with rich, interacting business rules that would be lost in a simple CRUD model.
  • Finance/Banking (complex instruments, risk management), Healthcare (patient workflows), Insurance (policies, claims), E-commerce (catalogs, dynamic pricing), Real Estate.
  • Systems where a long-term, evolvable codebase is more important than initial speed.
  • Teams that have (or can develop) access to knowledgeable domain experts.

Trade-offs

Pros:

  • Software that accurately reflects the business domain is easier to evolve when the business changes.
  • Ubiquitous Language eliminates translation overhead and reduces misunderstandings between business and engineering.
  • Bounded Contexts provide natural microservice boundaries.
  • Tactical patterns (Entities, Value Objects, Domain Events) make complex invariants explicit.
  • Improved testability through well-defined domain objects.

Cons / pitfalls:

  • High upfront cost — requires deep domain understanding before writing significant code.
  • Overkill for simple CRUD applications or supporting/generic subdomains.
  • Requires buy-in from both technical and domain expert sides.
  • The learning curve for the full DDD toolkit is steep.
  • Mismodeled Bounded Context boundaries create more coordination overhead than they save.
  • Difficulty aligning multiple models across bounded contexts; technology integration with legacy systems is complex.

Real-World Example: Ride-Hailing Application

Bounded Contexts:

  • Ride Management (lifecycle, requests, status)
  • User Management (authentication, history)
  • Driver Management (availability, ratings)

Entities: User, Driver, Ride Request, Ride
Value Objects: Location (latitude/longitude)
Aggregate: Ride aggregate (root entity coordinating related entities)
Domain Events: RideRequestedEvent, RideAcceptedEvent
Scenario: User requests ride → RideRequestedEvent triggered → Driver accepts → status: “In Progress” → Completed → fare calculated

Real-World Usage

  • Hospital management: Developers model how hospitals operate — appointments, patient histories, surgical workflows — before implementing. The software reflects the actual healthcare domain, not just database tables.
  • Widely adopted across ecosystems — DDD frameworks and libraries exist for most languages and runtimes; consult the sources section for specific examples.
  • Fowler recommends Evans’s original book as a worthwhile investment despite its difficulty, alongside Vaughn Vernon’s Implementing Domain-Driven Design (2013) for strategic design.

Tactical Design: Insurance Policy Example (Laribee)

David Laribee’s insurance domain case study illustrates DDD tactical patterns concretely:

  • Policy is an Aggregate Root — it enforces invariants about coverage, deductibles, and premium.
  • Deductible is a Value Object — immutable, defined by its amount and type, no identity of its own.
  • InsuredPerson is an Entity — has identity that persists across policy renewals.
  • An Anti-Corruption Layer translates legacy claim-processing terminology (using “Contract” where the domain says “Policy”) at the integration boundary.

Laribee’s “Platonic Forms” metaphor: an Order in code is an imperfect representation of the ideal order concept — model the ideal, not the database table.

Large-Scale DDD Patterns

For domains too large for a single model (enterprise logistics, banking, healthcare), Evans described additional patterns beyond the tactical building blocks:

  • Responsibility Layers — stratifies the domain into layers of increasing abstraction (Capabilities → Operations → Policies → Commitments → Decision Support); higher layers express intent, lower layers express mechanism.
  • Knowledge Level Pattern — separates base-level operational instances from meta-level type/rule objects, enabling configurable behavior without code changes.

See DDD Advanced Patterns for a synthesis of large-scale DDD including domain distillation and legacy modernization strategies.

Empirical Evidence (DDD Systematic Literature Review)

A 2023 systematic review of 36 DDD studies found:

  • DDD is most commonly adopted in microservices contexts (44% of studies), confirming Bounded Context as the natural microservice boundary.
  • Bounded Context is the most frequently applied strategic pattern in practice.
  • Main adoption challenges: steep learning curve, need for sustained domain expert involvement, and inconsistent interpretation of patterns across teams.

Legacy Modernization with DDD (Evans)

Four strategies for introducing DDD into a legacy system:

  1. Bubble Context — carve out a new bounded context that calls the legacy system via an ACL; the bubble gradually expands.
  2. Autonomous Bubble — a new context that duplicates necessary data from legacy, decoupling it completely.
  3. Exposing Legacy as Services — wrap the legacy system behind a published language so new bounded contexts can call it cleanly.
  4. ACL Wrapping — place an Anti-Corruption Layer around the legacy system; new contexts translate through the ACL rather than conforming to legacy semantics.

Graph View

Backlinks