How I sliced your app
summary
Argues for starting with a monorepo and splitting code by bounded contexts not layers, shows how to enforce one‑way dependencies with dab track and namespace‑internal declarations, and insists on testing + deploying every change. Demonstrates tradeoffs: RPC microservices multiply downtime (99.9% availability across six services yields ~94.1%), so prefer event‑driven subsystems and workers or use a Strangler pattern to rewrite safely. Gives concrete tools and rules rather than high‑level platitudes.
AI-written summary · about
chapters (20)
- 0:00Start
- 2:49Software architecture is a complex landscape
- 3:22Team types
- 4:30Small team
- 6:36the prototype
- 10:22Open Source
- 11:41Only administrators use the system
- 14:58What can influence?
- 17:34How do we identify a subsystem?
- 19:28Start with a monorepo
- 28:22Continuous Integration
- 30:40Won't the repository become enormous?
- 34:51check your dependency graph for gaps!
- 35:17Shipping
- 36:15Deployment
- 38:06Microservices?
- 41:49Monolithic system?
- 43:36divide into repositories?
- 45:29Will it blend?
- 48:46Questions?
related talks
01h 03mMicroservices vs The Distributed Monolith
54mServices, Services, Everywhere!
48mExperiences scaling a modular monolith to microservices using the 4+1 views
45mHow I learned to stop worrying and love the monolith
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
50mEmbracing Microservices
34mLevel up with a Microservices architecture
57mBuilding Systems that are #neverdone