Decomposition Patterns
summary
Eight concrete refactorings turn a monolith into a controlled service architecture: identify and size components, flatten root namespaces to eliminate orphaned classes, map component dependencies with tools like x-ray and SonarGraph and measure feasibility (example: 57 components, 23 in .shared; one component held 33% of code). Workflow: create component domains, extract to separate projects, deploy domain services, then selectively convert to microservices. Real results: some migrations finish as service-based architecture, others become multi‑year rewrites when dependency graphs look like a ball of yarn.
AI-written summary · about
chapters (8)
- 0:00Introduction to decomposition
- 4:00Identifying and sizing components
- 15:01Flattening component hierarchy
- 30:37Analyzing component dependencies
- 41:50Forming component domains
- 45:02Extracting domain services
- 47:29Moving to microservices
- 57:31Summary and Q&A
related talks
23mArchitecture Remediation
52mWhat Does a Good Microservice Architecture Look Like?
46mArchitectural Patterns and Approaches Supporting Refactoring(...)
49mFrom Macro To Micro
01h 01mMonolith Decomposition Patterns
57mModularizing the Monolith
32mSplitting the monolith
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
