Modularization: Foundation of Microservices and Monoliths
summary
Modularization reduces cognitive load by hiding design decisions and data so teams change only the module they need; the talk cites Parnas 1971 and advocates information hiding across levels from methods to systems, using CRC cards, the bounded context canvas and event‑storming to shape coarse modules. Practical guidance: don’t share databases or large event payloads, use metrics (e.g. cyclomatic complexity) to find fat modules, expect microservices to be “high‑risk, high‑gain” and plan cross‑service refactors and deployment processes.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:23Modularization: Limit Knowledge
- 2:05Modularization: Loose Coupling
- 3:00Modularization: Why?
- 3:36Netflix Architecture
- 4:39Why Netflix Works?
- 7:22Parnas in Criteria for Modulariza
- 9:11Parnas in Criteria Still Valid?
- 11:29Information Distribution Aspect
- 13:02Parnas Module
- 13:25Modern Modules
- 15:42Organization
- 16:18Modules & Sizes
- 17:38Coarse Grained Information Hicks
- 19:22CRC Cards for Classes
- 21:46Team
- 21:56Great Modules: Not too Fat
- 22:27Great Classes / Methods
- 26:22Loosely Coupled Modules
- 26:33Badly Designed Modules
- 27:58Well Designed Modules
- 30:28Microservices & Parnas
- 35:18Bounded Context Example
- 39:04Bounded Context & Modules
- 39:59Conclusion
related talks
01h 04mModular Monoliths and Other Facepalms
01h 01mModular Monolith Instead of Microservices: How, When and Why
47mModular Monoliths
57mModularizing the Monolith
43mModular Monoliths: The Architecture That Scales w Your Domain
59mMajestic Modular Monoliths
48mModularization — It Was Supposed to Be Beautiful but Turned Out as Usual :(
55mIs it Time to Abandon Microservices? Modular Monoliths Rescue Your Wallet!