Domain-Driven Design

Domain-driven design (DDD) is an approach to building software in which the design of the code mirrors the structure and language of the business domain it serves. Introduced by Eric Evans, it puts the domain model at the center of development and aligns engineers and domain experts around a shared vocabulary.

How It Works

DDD has strategic and tactical aspects. Strategically, teams identify bounded contexts — areas of the system where a particular model and its terms apply consistently — and define how those contexts relate. Within each context, the team develops a ubiquitous language: the same precise terms used in conversation, code, and documentation. Tactically, DDD offers building blocks such as entities (objects with identity), value objects (defined by their attributes), aggregates (consistency boundaries), repositories, and domain events to express the model in code.

Why It Matters

Most software fails not from weak technology but from misunderstood business rules. By forcing the model to match the domain and keeping language consistent, DDD reduces translation errors between business intent and implementation. Bounded contexts also give natural seams for splitting a system, which is why DDD heavily influences microservice and modular-monolith design: each service or module ideally maps to one context.

DDD is not free. It demands real domain-expert involvement and is overkill for simple CRUD applications. It pays off in complex domains where the business logic itself is the hard part.

Related Terms

A bounded context is DDD's central strategic unit. CQRS is often applied within a context. Microservices and the modular monolith use bounded contexts as boundaries.