Realizing Domain Design Through Architectural Modularity ...
summary
Argues that domains must map to architectural modules and that service granularity is justified by measurable trade-offs, not handwaving. Demonstrates five modularity drivers — maintainability, testability, deployability, scalability, fault tolerance — and contrasts them with disintegration vs integration drivers like code volatility, scalability/throughput, transactions, data coupling and workflow. Uses concrete numbers and timings (23 vs 12,000 tests, 220,000 texts a minute, mean startup 200–6,000 ms) to show when to split services, when to keep a bounded context together, and the risk of a distributed monolith.
AI-written summary · about
chapters (8)
- 0:00Introduction to modularity
- 1:40Why modularity matters
- 8:29Five drivers for modularity
- 19:51Modular monolith vs distributed
- 22:23Domain design in architectures
- 26:58Service granularity explained
- 45:52Balancing granularity drivers
- 47:16Q&A and closing
related talks
01mModularization: Foundation of Microservices and Monoliths
43mMonolith? Microservices? Who cares?
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
51mModularization: Foundation of Microservices and Monoliths
47mModular Monoliths
01h 02mDesigning Microservices
01h 04mModular Monoliths and Other Facepalms
57mUnderstanding the Differences Between Modularity and Granularity