Microservices and Domain-Driven Design — The Strategic Parts
summary
Domain-driven design defines service boundaries by modeling bounded contexts from business subdomains, not code structure; teams start with a medium-sized core subdomain (pricing in ride‑share) and use event storming plus context maps to find seams. Beware tactical splits that produce shared database with 20 microservices; prefer explicit mappings like anti-corruption layer or published language. The approach requires domain experts, iterative experiments, and accepts that anti‑corruption translation is costly but protects local ubiquitous language.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:44Why domain-driven design
- 7:25Technology as strategic advantage
- 11:59Domain over code
- 13:25Domains and subdomains
- 17:19Identifying domains
- 23:28Strategic patterns matter
- 26:16Ubiquitous language
- 29:48Problem vs solution space
- 31:55Context mapping explained
- 41:25Event storming technique
- 44:15Finding true seams
- 46:25Collaboration and iteration
- 48:13Focus on competitive advantage
- 50:46Resources and closing
related talks
49mDDD & Microservices: At Last, Some Boundaries!
40mMicroservices without DDD is risky business!
01h 00mFrom Domain Driven Design DDD to Delivery
44mStrategic Domain-Driven Design for dummies
55mDomain-Driven Design: back to the roots
47mDomain-Driven Design: A Complete Example
38mWhat I talk about when I talk about Domain Driven design
47mGetting modules right with Domain-driven Design