Microservices? Monoliths? Modules!
summary
Claim: complexity comes from bad modularization not from microservices or monoliths. Evidence: an old project takes 50 minutes to start, another release cycle needs 10 weeks of testing before a quarterly deploy. Observations: 90% of Java packages form dependency cycles, thousands of microservices mean wrong module granularity. Remedies actually used: define bounded contexts with a bounded context canvas, use event‑storming, hide data (no shared schemas), apply hexagonal ports/adapters. Netflix remains functional, so successful modularization scales.
AI-written summary · about
chapters (9)
- 0:00Start
- 3:09My First Large Project
- 7:25Netflix Architecture
- 11:29Typical Monolith Architecture
- 14:08Organization
- 19:43Information Distribution Aspects
- 22:28CRC Cards for Classes
- 23:46Bounded Context Canvas
- 29:19Bounded Context Example
related talks
57mModularizing the Monolith
19mMicroservices vs. Monolith for Scalability and Efficiency
23mMicroservices within a Monolith
39mConsidering Migrating a Monolith to Microservices?
49mChallenges in Implementing Microservices
37mEvolutionary Architecture & Microservices
46mFrom Chaos to Cohesion: Building Modular Monoliths in the Real World
01h 04mPractical advice for building glorious monoliths