Domain-Driven Design: Bounded Contexts, Aggregates, and Context Maps

Why Domain-Driven Design?

Domain-Driven Design (DDD) is an approach for building software around the business domain instead of around tables, screens, or technical layers. It is most useful when the domain is complex, language matters, and different parts of the business use similar words with different meanings.

Strategic vs Tactical DDD

DDD has two major levels.

Use strategic DDD before tactical DDD. Clean entities do not help much if the service boundaries are wrong.

Ubiquitous Language

Ubiquitous language means engineers and domain experts use the same precise language in conversations, diagrams, tests, code, and APIs.

Example: E-Commerce

DDD forces the team to clarify these meanings.

Bounded Contexts

A bounded context is a boundary inside which a model has one clear meaning. The same term may mean something different in another bounded context.

Bounded Context Heuristics

Bounded contexts often become service boundaries, but they do not have to. A modular monolith can still have excellent bounded contexts.

Subdomains

Subdomains classify parts of the business by importance and differentiation.

For a food delivery company, dispatch optimization might be core, restaurant onboarding might be supporting, and payroll might be generic.

Context Mapping

Context maps describe relationships between bounded contexts. This matters because no context is isolated forever.

Common Context Relationships

Anti-Corruption Layer

An anti-corruption layer (ACL) protects your domain model from an external or legacy model.

The ACL translates terms, validates assumptions, and prevents legacy concepts from leaking everywhere.

Entities and Value Objects

Entity

An entity has identity that continues over time even when its attributes change.

class Customer {
  constructor(
    public readonly id: CustomerId,
    public email: EmailAddress,
    public status: CustomerStatus
  ) {}
}

Value Object

A value object is defined by its values. It is usually immutable and has no separate identity.

class Money {
  constructor(
    public readonly amount: number,
    public readonly currency: string
  ) {
    if (amount < 0) throw new Error("Money cannot be negative");
  }
}

Aggregates

An aggregate is a cluster of domain objects that must be consistent together. The aggregate root is the only object external code should reference directly.

Aggregate Rules

1. Protect invariants inside the aggregate.
2. Only modify children through the aggregate root.
3. Keep aggregates small.
4. Reference other aggregates by ID, not object graph.
5. Use domain events for cross-aggregate coordination.

Example Invariant

class Order {
  private lines: OrderLine[] = [];
  private status: "draft" | "placed" = "draft";

  addLine(productId: string, quantity: number) {
    if (this.status !== "draft") {
      throw new Error("Cannot change a placed order");
    }
    if (quantity <= 0) {
      throw new Error("Quantity must be positive");
    }
    this.lines.push({ productId, quantity });
  }

  place() {
    if (this.lines.length === 0) {
      throw new Error("Cannot place an empty order");
    }
    this.status = "placed";
  }
}

Repositories, Services, and Domain Events

Domain events should describe facts in the domain language: OrderPlaced, PaymentCaptured, ShipmentDelayed.

DDD and Microservices

DDD helps you find good service boundaries, but it does not require microservices.

Common DDD Mistakes

What to Remember for Interviews

1. Ubiquitous language: Code should reflect the language of the domain.
2. Bounded contexts: A model is valid inside a boundary, not across the whole company.
3. Context maps: Define how contexts integrate and depend on each other.
4. Aggregates protect invariants: They are consistency boundaries, not just object graphs.
5. DDD informs architecture: It helps choose module and service boundaries.