Drawing the right lines: DDD, APIs and Microservices
summary
Claim: most teams cannot justify their service boundaries — about 75–80% of designs get no real rationale — so this gives concrete fixes: assess organizational reversibility and core business goals, constrain scope to a single core domain, and validate boundaries quickly with code or lightweight tests. Recommended tools include event storming, event modeling, microservice canvas and context maps, run virtual workshops with Mural/Miro plus prework interviews, target Kubernetes/AWS proofs of concept, and bake KPIs for when to split or merge domains so models stay alive in code.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 5:10About Ronnie Mitra
- 6:22The microservices world
- 7:00Domaindriven design
- 9:31Boundaries
- 11:09Practical tips
- 11:46Situational assessment
- 15:07Design
- 18:29Covid
- 19:45Domain models
- 24:29Wrap up
related talks
56mMicroservices and Domain-Driven Design — The Strategic Parts
01h 02mDesigning Microservices
49mDDD & Microservices: At Last, Some Boundaries!
41mA practical tale of assessing a Microservices Architecture
50mFinding Your Service Boundaries - a Practical Guide
56mDesigning in the World of Microservices
40mMicroservices without DDD is risky business!
16mMicroservices Paradise: is it possible to achieve?