Patterns for Software Architecture
summary
Argues that architecture choices follow from prioritized system characteristics not from fashionable patterns; instructs teams to list and rank requirements, prototype, then pick an architecture. Distinguishes monolith vs distributed by the unit of deployment, warns against reflexive microservices, and recommends service-based architecture (incremental code split with shared DB) as pragmatic. Gives concrete caution — an enterprise table with 800 columns breaks agility — and urges prototyping to reveal real trade-offs.
AI-written summary · about
chapters (15)
- 0:00Introduction to patterns
- 1:47What are software patterns
- 4:36Patterns as communication tools
- 7:11Start with requirements not patterns
- 12:32Identify system characteristics
- 18:58Common system characteristics
- 23:19Monoliths vs distributed systems
- 27:56When to choose monoliths
- 33:16Why distributed architectures
- 41:27Bounded contexts in architecture
- 47:07Monolithic architecture types
- 49:18Distributed architecture types
- 55:41When microservices make sense
- 58:10Prototyping and decision making
- 59:57Summary and key takeaways
related talks
57mSoftware Architecture: The Hard Parts
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
50mTowards an Evolutionary Architecture
52mMeta modern Software Architecture
01h 13mPragmatic Architecture
36mApplication Architecture Patterns
54mArchitecture Is Not Nonsense
45mFive things every developer should know about software architecture