Start with DDD when you have a monolith
summary
Uses event storming to find domains and bounded contexts, then targets the worst pain — booking — and spends about eight months to the first delivery. Applies a strangler fig pattern, extracts a few microservices while keeping the monolith, and enforces testing (TDD, mutation and contract tests), CI checks, cucumber/cypress for post-deploy tests, monitoring and tracing. Adds ArchUnit architecture tests and C4 diagrams for documentation. Result: fewer outages, clearer team responsibilities and faster adaptability when traffic spikes hit.
AI-written summary · about
chapters (12)
- 0:00Introduction to monoliths
- 3:04The big ball of mud
- 5:54Introducing DDD
- 8:53Airline case study
- 12:20Event storming & modeling
- 16:11Planning the migration
- 19:55Strategic refactoring
- 23:58Testing and monitoring
- 25:35Final structure and outcome
- 27:52Maintaining architecture
- 31:13Documentation and summary
- 34:05Final thoughts
related talks
45mUsing DDD To Decompose Your Monolith
01h 00mFrom Domain Driven Design DDD to Delivery
51mDomain - Driven Transformation
47mDomain-Driven Design: A Complete Example
47mDomain Driven Transformation—How to Bring Back Sustainable Architecture to
38m7 Years of DDD: Tackling Complexity
53mCrafting a self-documenting Modular Monolith with DDD principles (theory not included)
02h 29mPractical advice for building glorious monoliths