Cheat sheetCD-01

Domain-Driven Design

Core Design / Domain-Driven Design

DDD aligns the software model with the business through a ubiquitous language, and carves systems into bounded contexts and subdomains so complexity stays local and meaning stays consistent.

01
Ubiquitous languageOne business-derived vocabulary shared by experts and code alike; divergence signals model drift.
02
Bounded contextThe boundary within which a model and its language are consistent; the same term may differ across contexts.
03
SubdomainsCore (differentiator, invest), supporting (necessary, keep simple), generic (solved, buy).
04
Aggregate + context mapAggregate = transactional consistency boundary via a root; context map = how contexts integrate.
⚑

Start strategic: classify subdomains and draw the context map before diving into aggregates. Invest tactical richness only in core subdomains; keep supporting simple and buy generic. Guard each aggregate's invariants through its root, and use anti-corruption layers where an upstream model would otherwise corrupt yours.

Same word, two models'Shipment' is a priced quote in Sales but a set of routed legs in Routing — each valid inside its own bounded context.
Invariant at the rootA Routing aggregate enforces 'a leg's origin equals the previous leg's destination' through its root so it is never inconsistent.
Subdomain: core | supporting | generic
Bounded context = model + ubiquitous language boundary
Aggregate root => guards invariants (transactional boundary)
Context map: Partnership, Customer/Supplier, Conformist, ACL
dddbounded-contextsubdomainsaggregatescontext-map
review in 6d