Microservices without DDD is risky business!
summary
Claim: upfront Domain‑Driven Design prevents microservices from becoming distributed monoliths. Practical techniques shown include bounded contexts, ubiquitous language and aggregates, plus business capability mapping and evented interfaces. Examples from telecom expose the shared‑database anti‑pattern and an aggregate enforcing subscription invariants; many organizations end up with hundreds or thousands of tiny services that increase coupling. Recommendation: start with a modular monolith or coarse domains, carve services by domain models, use events to keep autonomy, and migrate via MVPs.
AI-written summary · about
chapters (8)
- 0:00Start
- 2:24SAY MICROSERVICE
- 17:52Domain Driven DESIGN
- 21:12Strategic patterns
- 24:17Subdomains
- 29:51Tactical patterns
- 32:00Taxonomy
- 37:01A complex system that works is invariably found to have evolved from a simple system that worked
related talks
56mMicroservices and Domain-Driven Design — The Strategic Parts
49mDDD & Microservices: At Last, Some Boundaries!
56mDDD in Microservices: Complexity versus Complexity
45mUsing DDD To Decompose Your Monolith
43mHow to Avoid Doing Microservices Completely Wrong
49mMicroservices guided by DDD and reactive systems paradigm
01h 02mDesigning Microservices
01h 00mPrinciples for Building MicroServices