Model Mitosis: Stop making the wrong choice between microservices and monolith
summary
A concrete recipe for splitting a growing domain by behavior rather than by guesswork, demonstrating on a toy “space train” app how to extract features into Model Mitosis, create a shared kernel then shrink and duplicate models (e.g., Fair → FairOption/SelectedFair), and move an anti‑corruption layer out to avoid contamination. Shows tests, CI fixes, and a past‑booking bug resolved; argues use of an off‑the‑shelf money library (Yoda‑Money) and metrics (roughly 10 searches per booking, search short‑lived vs booking 3+ months) to decide when to adopt separate runtimes or keep a modular monolith.
AI-written summary · about
chapters (11)
- 0:00Space train MVP intro
- 4:13Booking feature demo
- 7:59Microservices vs monolith
- 13:19Domain boundaries via behaviors
- 18:00Split domains: search and booking
- 23:23Shared kernel for shared concepts
- 28:43Tax computation feature
- 34:01Debugging past bookings
- 38:15Need for microservices?
- 42:30Model meiosis pattern
- 45:39Conclusion & Q&A
related talks
48mModel Mitosis: Stop Confusing Microservices and the Monolith
50mModel Mitosis: a dynamic pattern to deal with model tensions
51mModel Mitosis: No More Confusing Microservices with Monoliths
50mModel Mitosis: No More Confusing Microservices and the Monolith
49mMitosis Pattern
47mMicroservices? Monoliths? An Annoying Discussion!
45mMonolith to Microservices: Modularizing Fineract 1.x
34m"Taming your Rails monolith"