principle-dddlisted

# Domain-Driven Design DDD is a toolkit for **complex domains**. For CRUD, it is overkill. ## Strategic design ### Ubiquitous language Every important concept in code uses the same word the domain experts use. If marketing says "subscription" and code says "userPlan", you have a translation tax forever. Rename. ### Bounded contexts A bounded context is a boundary inside which a term has exactly one meaning. "Order" in Checkout is not the same entity as "Order" in Fulfillment — it just shares a name. - One team, one context is the ideal. - Cross-context communication goes through explicit contracts (events, APIs). - Shared databases across contexts are an anti-pattern. ### Context map Document how contexts relate: Partnership, Customer/Supplier, Conformist, Anticorruption Layer, Published Language, Shared Kernel, Separate Ways. Pick the relationship intentionally. ## Tactical design ### Entity Identity persists through change. `User{id, name}` — renaming doesn't change the user. Entities own their behaviour — **tell, don't ask**. Logic that enforces an entity's invariants belongs on the entity, not in a service that reads its fields and mutates them from outside. An entity that is pure data with all logic elsewhere is an **anemic domain model** — an anti-pattern. (See `principle-solid` § "If You Catch Yourself Thinking…" for the reflection-table form.) ### Value object Identity-less, immutable, compared by value. `Money{amount, currency}`, `EmailAddress`, `DateRange`.