Don't Panic — Domain-Driven Design

Domain-Driven Design is an approach to building software that starts from an uncomfortable observation: in most complex applications, the hard problem is not the technology. It is the business domain itself — the activity or process the software serves. The method, introduced by Eric Evans in 2003, says you should center your entire design effort on a shared, precise model of that domain, built in ongoing collaboration between the people who write code and the people who understand the business.

The two or three ideas everything else hangs off: Ubiquitous Language (a shared vocabulary between developers and domain experts, enforced in code), Bounded Contexts (the boundary within which one model and one language hold consistently), and Aggregates (consistency boundaries that define what must stay in sync within one transaction). If you remember only one thing a week later, make it this: a Bounded Context is not a technical boundary. It is a business boundary. The word "account" can mean different things in different parts of your system, and that is not a bug — it is two domain experts using the same word for two different concepts. DDD draws a boundary instead of forcing one meaning.

The thing that will surprise you: the hardest part is not learning the pattern names. It is getting domain experts into a room regularly and keeping them there. DDD is a collaboration methodology dressed up as a design pattern. Without that collaboration, you are building a rich domain model that nobody who understands the business has ever seen, which is a particularly expensive way to build a CRUD system.

Strategic design — naming subdomains, drawing bounded contexts, mapping how they relate — pays off independent of your coding style, because it is conceptual work that shapes the system before you choose a technology. Tactical design — entities, value objects, aggregates, domain events — pays off in proportion to how much real behavior and invariant-checking your domain actually needs. Full tactical modeling on a generic subdomain (user accounts, invoicing, authentication) is usually not worth it. That is exactly what "generic subdomain" means.

What to read next: the Slides tab walks through the strategic and tactical patterns with a visual overview. The Cheatsheet is the dense reference you will reach for when modeling a real system. The Quiz tests whether the distinctions stuck. And if you want to see the patterns in working code rather than diagrams, the Awesome Links tab points at the DDD Sample reference application and the tools practitioners actually use.

Don't Panic — Domain-Driven Design

Relevant careers