Book 09 · Software ArchitecturePage 15 of 48

Domain-Driven Design

Updated September 30, 20262 min read

In short

Domain-driven design is an approach to building software that models the code closely on the business domain, using the same language as the domain experts.

What is domain-driven design?

Domain-driven design, or DDD, is an approach introduced by Eric Evans in his 2003 book of the same name. It argues that the hardest part of most software is understanding the business problem, called the domain, so developers should work closely with domain experts and shape the code around how the business actually works. The domain might be shipping logistics, insurance claims, or online banking.

A core practice is the ubiquitous language: a shared vocabulary that developers and experts use in meetings, documents, and the code itself. If the business talks about a shipment being dispatched, the code has a Shipment class with a dispatch() method, not a generic updateStatus function. Large domains are split into bounded contexts, areas with their own consistent model and language; for example, a customer means something different to the sales team than to the support team.

DDD also offers building blocks for the model. Entities are objects with an identity that lasts over time, like an order with an ID; value objects are defined only by their values, like an amount of money; and aggregates are clusters of objects that must stay consistent together and are changed only through one root object. Domain events record important things that happened, such as OrderShipped.

An analogy is an architect who spends time with a hospital's doctors and nurses before designing the building, so the layout matches how they really work. DDD is often mixed up with microservices: bounded contexts are a helpful way to decide where service boundaries go, but DDD is about modeling and works just as well in a monolith. It pays off for complex business logic and is usually too heavy for simple CRUD applications.

Key takeaways

DDD shapes code around the business domain and the knowledge of its experts.
A ubiquitous language keeps business terms and code names the same.
Bounded contexts divide a large domain into areas with their own model.
Entities, value objects, and aggregates are its core building blocks.
It pays off for complex business logic, not for simple CRUD apps.

Example

A value object and an entity in TypeScripttypescript

// Value object: defined only by its values and never changed after creation
class Money {
  constructor(readonly amount: number, readonly currency: string) {}
}

// Entity and aggregate root: has an identity and protects its own rules
class Order {
  private status: "draft" | "placed" | "shipped" = "draft";
  constructor(readonly id: string, readonly total: Money) {}

  ship() {
    if (this.status !== "placed") throw new Error("Only placed orders can ship");
    this.status = "shipped"; // named in the business's own language
  }
}

Readers ask

What is a bounded context in DDD?

A bounded context is a clear boundary within which a particular domain model and its terms have one consistent meaning. Different contexts, such as billing and shipping, can each have their own model of the same real-world thing, like a customer.

Is domain-driven design the same as microservices?

No. DDD is an approach to modeling business logic, while microservices are a way of deploying a system as separate services. Bounded contexts are often used to decide microservice boundaries, but DDD works equally well inside a monolith.

When should you use domain-driven design?

DDD is most valuable when the business rules are complex and change often, such as in finance, logistics, or healthcare. For simple CRUD applications that mostly read and write data, its practices usually add more overhead than benefit.