Domain-Driven Design (DDD) is an approach to software design that focuses on modeling the business domain accurately. It uses a shared language (ubiquitous language) between developers and domain experts, and organizes code around bounded contexts — self-contained models for specific business areas.

How Domain-Driven Design Works

In an e-commerce system, 'Product' means different things in different contexts: the Catalog context cares about descriptions and images; the Inventory context cares about stock levels and warehouses; the Pricing context cares about discounts and taxes. DDD says these are separate bounded contexts with separate models.

Key Concepts

  • Bounded Context — A boundary within which a domain model has a specific, consistent meaning
  • Ubiquitous Language — Shared vocabulary between developers and business experts — used in code, conversations, and docs
  • Aggregate — A cluster of domain objects treated as a unit — the root entity controls access and enforces invariants
  • Domain Events — Events that capture something meaningful that happened in the domain — OrderPlaced, PaymentReceived

Frequently Asked Questions

When should I use DDD?

When the business logic is complex and the domain is the core differentiator. E-commerce, finance, healthcare, logistics. Don't use DDD for simple CRUD apps or technical tools.