Using DDD To Decompose Your Monolith
summary
Argues that decomposing a monolith with Domain-Driven Design yields vertical, activity-aligned components that each own their data so referential integrity no longer forces global changes. Shows splitting a User into authentication, customer contact, billing and shipping bounded data models, recommends the strangler pattern and asynchronous communication via NServiceBus plus ServiceControl/ServiceInsight, warns that naive rewrites fail and that one migration once took three months of physical data transfer.
AI-written summary · about
chapters (8)
- 0:00Introduction and welcome
- 1:48The monolith problem
- 10:22Why rewrites fail
- 13:54Introducing DDD
- 23:47Bounded contexts explained
- 34:06Decomposing the monolith
- 36:38Q&A session
- 41:00Final thoughts and summary
related talks
02h 31mSlice & Dice your Monolith with Domain Driven Design
40mMicroservices without DDD is risky business!
45mDon't Overdose on Domain-Driven Design
44mStrategic Domain-Driven Design for dummies
02h 29mPractical advice for building glorious monoliths
37mStart with DDD when you have a monolith
53mDeconstructing the monolith
29mFrom Monolith to Cloud-Ready Microservice Architecture with DDD