Modularizing the Monolith
summary
Monoliths become hard to change because boundaries are missing; the practical fix is to refactor into a vertical slice architecture so each user operation lives front-to-back, then group slices into modules that contain data and a public API. Independence is measurable by counting incoming/outgoing dependencies and spotting hot spots (one case shows 200+ usages between modules, and organizations can explode to thousands of microservices). Static analysis yields a dependency matrix and the DB migration follows a staged approach popularized by Stripe: migrate schema by dual-writing, switch readers, then drop old writes.
AI-written summary · about
chapters (13)
- 0:00Modularizing the monolith
- 3:55Microservices vs monoliths
- 7:47Good vs bad monoliths
- 10:13Layered architectures fail
- 12:02Vertical slice architecture
- 15:36Independent modules
- 17:43Module boundaries in code
- 20:50Data ownership in modules
- 25:30Refactoring to vertical slices
- 34:30Database refactoring
- 41:59Measuring module independence
- 45:10Extracting modules
- 53:20Key takeaways
related talks
59mMajestic Modular Monoliths
43mModular Monoliths: The Architecture That Scales w Your Domain
51mModularization: Foundation of Microservices and Monoliths
01h 01mModular Monolith Instead of Microservices: How, When and Why
48mMicroservices? Monoliths? Modules!
42mQ&A - Monolith to Microservices
50mMajestic Modular Monoliths
39mConsidering Migrating a Monolith to Microservices?
