Evolutionary Architecture: How do you build systems that can evolve?
summary
Advocates defining an explicit fitness function (a 0–10 score) across dimensions like auditability, performance, security and data, then guiding small incremental changes by that score. Uses patterns: event sourcing with immutable event logs, CQRS for read models, async messaging (Kafka/message bus) for tiered services, sagas for rollbacks, and distributed tracing (Jaeger) for observability. Recommends loose contracts, versioned schemas, modular monoliths before premature microservices, avoid stored procedures, expect eventual consistency (milliseconds), and treat data as longer‑lived than applications.
AI-written summary · about
chapters (14)
- 0:00Evolutionary architecture intro
- 2:37Problem definition & software rot
- 8:59Coupling & cohesion
- 13:33DDD & bounded contexts
- 17:04Layered architecture & monolith
- 19:50Microservices trade-offs
- 22:40Loosely coupled communication
- 25:30Event sourcing benefits
- 28:21Command query responsibility segregation
- 30:52Sagas for long transactions
- 32:18Evolutionary data principles
- 35:05Microservices data schemas
- 37:14Conway's law & teams
- 37:56Best practices
related talks
53mEvolutionary Architecture: Principles and Patterns
49mThe Principles of Evolutionary Architecture
01h 03mEvolutionary Software Architectures
39mHow will Evolutionary Architecture evolve?
42mBuilding Evolutionary Architectures: Principles and Practices
39mPrinciples of Evolutionary Architecture
35mPrinciples of Evolutionary Architecture
01h 00mEvolutionary Architectures