Domain-Driven Design

Overview

Domain-Driven Design (DDD), introduced by Eric Evans, is an approach to building software around a deep model of the business domain, developed together with domain experts using a shared ubiquitous language. It has two parts: strategic design (splitting a large domain into bounded contexts and mapping their relationships) and tactical design (patterns like entities, value objects, aggregates, domain events, repositories).

Bounded contexts are the most important idea for system design: each context has its own model and language (a 'Product' means different things to Catalog and Shipping), and they make natural boundaries for modules or microservices. Aggregates define consistency boundaries: invariants are enforced within one aggregate in one transaction, while cross-aggregate consistency is eventual.

When to use it

• Complex business domains (insurance, logistics, finance, healthcare).
• Finding service or module boundaries.
• Teams struggling with inconsistent terminology and tangled models.
• Designing consistency and transaction boundaries.

Where it shows up in interviews

Where it is used in real software

Key terms

Ubiquitous language

Shared terms used by developers and domain experts, in code too.

Bounded context

Boundary within which a model and language apply consistently.

Aggregate

Cluster of objects treated as one unit for changes, with a root.

Value object

Immutable, identity-less object defined by its values (Money).

Domain event

Something important that happened (OrderPlaced).

Context map

Relationships between contexts (upstream/downstream, anti-corruption layer).

How it works, step by step

1. 1
   Explore the domain with experts

   Event storming to find events, commands, and actors.

2. 2
   Identify bounded contexts

   Where language and models change.

3. 3
   Map context relationships

   Who depends on whom; add anti-corruption layers.

4. 4
   Design aggregates

   Small, enforcing invariants in one transaction.

5. 5
   Integrate with domain events

   Cross-aggregate and cross-context consistency is eventual.

Bounded contexts in e-commerce

Same word, different models

Each context can be a module or service with its own data; they share IDs and events, not one giant Product table.

Implementation

1// Value object: immutable, compared by value2export class Money {3  private constructor(readonly cents: number, readonly currency: "USD" | "EUR") {}4  static of(cents: number, currency: "USD" | "EUR") {5    if (!Number.isInteger(cents) || cents < 0) throw new Error("Invalid amount");6    return new Money(cents, currency);7  }8  add(other: Money) {9    if (other.currency !== this.currency) throw new Error("Currency mismatch");10    return Money.of(this.cents + other.cents, this.currency);11  }12}13 14// Aggregate root: all changes go through it, invariants enforced inside15export class Order {16  private lines: { sku: string; qty: number; price: Money }[] = [];17  private status: "draft" | "placed" = "draft";18  readonly events: { type: string; orderId: string }[] = [];19 20  constructor(readonly id: string) {}21 22  addLine(sku: string, qty: number, price: Money) {23    if (this.status !== "draft") throw new Error("Cannot modify a placed order");24    if (this.lines.length >= 50) throw new Error("Too many lines");25    this.lines.push({ sku, qty, price });26  }27 28  place() {29    if (this.lines.length === 0) throw new Error("Empty order");30    this.status = "placed";31    this.events.push({ type: "OrderPlaced", orderId: this.id }); // other contexts react asynchronously32  }33}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• One huge aggregate.

  Fix: Causes lock contention and big transactions; split by invariants.

• Applying tactical patterns without strategic design.

  Fix: Bounded contexts matter more than repositories and factories.

• A single canonical enterprise model.

  Fix: Let each context have its own model.

Interview questions

Practice problems