| name | architecture-paradigm-domain-driven |
| role | library |
| description | Models a business in its own language. Use when the domain has real business rules to capture. |
| alwaysApply | false |
| category | architectural-pattern |
| tags | ["architecture","domain-driven-design","ubiquitous-language","bounded-context","anti-ceremony"] |
| dependencies | [] |
| tools | [] |
| usage_patterns | ["paradigm-implementation","domain-modeling","legacy-decomposition","adr-support"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 1400 |
The Domain-Driven Design Paradigm
Design for the future, build for now.
DDD is modeling a business in the business's own language. The goal is not
to avoid structure. It is to avoid structure you cannot back out of, and to
defer structure you do not yet need.
What DDD Is
Ubiquitous language, bounded contexts, and a model built by talking to the
people who do the work. The measure of a domain model is whether a person
in the business would recognize their own job in it.
What DDD Is Not
Clean Architecture. Mandatory layering. A mapper between every tier. A
count of design patterns applied before the first line of business logic is
written.
These are DDD-adjacent choices. Each has its own justification, and none of
them is entailed by DDD. Wanting to decouple an API from the domain is a
good reason to add a DTO. "This is what DDD requires" is not, because it
does not.
Strategic Design Is The Core
The building blocks are not the point, and this is not the repo's opinion.
Evans said so himself, ten years after the book, about the book:
"things like the entities and value objects [..] [People] come away
thinking that that's really the core of DDD, whereas, in fact, it's
really not."
"I really think that the way I arranged the book gives people the wrong
emphasis, so that's the biggest part of what I do is rearrange those
things."
Source: SE-Radio Episode 226, "Eric Evans on Domain-Driven Design at 10
Years" (video). Quotes as
transcribed by The Core of Domain-Driven
Design,
which also cites his DDD Europe 2016 keynote criticizing the
"over-emphasis on building blocks."
What the core actually is: discovering subdomains and drawing bounded
contexts, in language the business already speaks. Entities, value objects,
and aggregates are how a model reaches code once it exists. They are the
translation, not the thing being translated.
Read the rest of this skill in that light. Every mechanism below is
optional machinery serving a model you found by talking to people.
When To Use
- The domain has business rules a domain expert could argue about.
- The team can talk to the people who do the work being modeled.
- The system is expected to grow into complexity you cannot yet name.
When NOT To Use
- Domains with no meaningful business rules (CRUD over a form).
- Single-actor tools with no business vocabulary to share.
- Anything where the model would be a database schema with a new name.
Build For Now
Once a domain exists, create the data store and one concrete data object.
Pass that object from the repository into the business layer. At the start
of a project, pass it out to the view as well.
