domain-driven-designlisted

# domain-driven-design — voidcorp craftsman edition The data model does not drive the design. The domain does. Inside a bounded context, every word has one meaning. Aggregates enforce invariants. Value objects model semantic primitives. The code uses the words the team uses. **Attribution**: see `.source` in this directory. Foundation: Evans 2003, Vernon 2013, Wlaschin "Domain Modeling Made Functional," Stemmler TS adaptation, Khorikov. --- ## Strategic DDD — the vocabulary | Term | Definition | |---|---| | **Bounded Context** | A boundary inside which a model is valid and a language is consistent. One context = one module/package. | | **Ubiquitous Language** | The shared vocabulary inside a context. Code uses the same words stakeholders use. Diverging is a bug. | | **Context Map** | The graph of bounded contexts and their relationships (partnership, conformist, anti-corruption layer, ...). Documented in `docs/CONTEXT-MAP.md` for non-trivial systems. | | **Aggregate** | A cluster of objects treated as a single unit for consistency. The aggregate enforces its own invariants. | | **Aggregate Root** | The single entity through which the aggregate is accessed. The only thing repositories return. | | **Entity** | An object identified by its identity (UserId), not its attributes. Two entities with the same fields but different IDs are distinct. | | **Value Object** | An object identified by its attributes. Two value objects with the same fields are equal. Immutable. | | **Doma