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. ### Value object Identity-less, immutable, compared by value. `Money{amount, currency}`, `EmailAddress`, `DateRange`. Prefer aggressively — eliminates primitive obsession bugs. ### Aggregate A cluster of entities and value objects treated as one consistency boundary. The **aggregate root** is the only entry point; outside code cannot hold references to internal entities. - Keep aggregates small — large ones cause contention. - One transaction, one aggregate. Cross-aggregate coordination happen