ddd-guidelisted

# Domain-Driven Design Find the boundaries in a domain, name everything inside them rigorously, and model each boundary with building blocks that keep business invariants honest. Strategic design draws the map; tactical design fills it in. ## Essentials - **Build one ubiquitous language per context** - bind agreed terms into both the model and the code, see [references/strategic-design.md](references/strategic-design.md) - **Draw bounded contexts before classes** - each context is a boundary of model consistency where words mean exactly one thing, see [references/strategic-design.md](references/strategic-design.md) - **Map contexts and shield with an anti-corruption layer** - translate foreign models both directions into your own terms, see [references/strategic-design.md](references/strategic-design.md) - **Distinguish entity from value object** - identity-over-time versus defined-by-attributes-and-immutable, see [references/tactical-building-blocks.md](references/tactical-building-blocks.md) - **Keep aggregates small with one root** - protect true invariants in a transaction, reference other aggregates by id, see [references/tactical-building-blocks.md](references/tactical-building-blocks.md) - **Hand whole aggregates through a repository** - persistence-ignorant, collection-like access to roots only, see [references/tactical-building-blocks.md](references/tactical-building-blocks.md) ## Gotchas - A bounded context is not a microservice or a subdomain: it is a solution