Level 6: Domain-Driven Design
Model a complex business domain in code, and draw boundaries where the language changes. Level 6 of 11: 8 lessons on domain-driven design. Based on DDD.
Outcome: Model a complex business domain in code, and draw boundaries where the language changes.
Orders, subscriptions, invoices, shipments and refunds — ShopFlow’s domain is now the hard part. Tactical DDD gives us building blocks; strategic DDD tells us where the boundaries go.
The pressure on ShopFlow: “Customer” means five different things to five teams, and the model is a tangle.
Lessons in level 6
- Ubiquitous Language: Code That Speaks the Business — One shared vocabulary between experts and code, per boundary.
- Entities vs Value Objects — Identity vs value: why Address and Money should not have ids.
- Aggregates: Consistency Boundaries That Protect Invariants — Group objects that must change together, and guard them behind one root.
- Domain Services vs Application Services — Where logic goes when it does not belong to a single entity.
- Domain Events: Things That Happened — Model important facts explicitly and let other parts react.
- Bounded Contexts: Where Words Keep One Meaning — A boundary around a part of the business where the same words mean the same thing.
- Context Maps: How Bounded Contexts Relate — Anti-corruption layers, shared kernels, customer/supplier, open host and more.
- Strategic Design: Core, Supporting & Generic Subdomains — Invest where you compete; buy or simplify the rest.
Source books
- DDD — Eric Evans