DDD & Microservices: At Last, Some Boundaries!
summary
Argues that microservices give the concrete isolation needed for precise Domain‑Driven Design by making each service a bounded context with its own language and data, recommends no shared database and teams owning contexts, shows patterns: anti-corruption layer to translate messy upstream messages, interchange context when one service’s language becomes a de facto bus, cites Netflix inspiration and a message‑queue experiment, warns of conformity causing design decay and recommends explicit context maps.
AI-written summary · about
chapters (11)
- 0:00Intro
- 1:44Why Microservices
- 7:36What is a Service
- 9:11Understanding Messages
- 11:47AntiCorruption Layer
- 17:23Models
- 22:44AntiCorruption
- 29:15Logical Boundaries
- 32:55Concrete Boundaries
- 36:23Not all large systems will be well designed
- 37:21Questions
related talks
56mMicroservices and Domain-Driven Design — The Strategic Parts
40mMicroservices without DDD is risky business!
01h 00mPrinciples for Building MicroServices
56mDesigning in the World of Microservices
56mDDD in Microservices: Complexity versus Complexity
01h 02mDesigning Microservices
01h 01mArchitectural Principles and Practices to Build MicroServices
48mDesign principles to the rescue of micro-services