Architecture rarely decays because teams stop caring. It decays because change starts accumulating faster than the system can absorb it. This chapter shows how to make evolution deliberate instead of hoping one good diagram will survive production forever.
The strongest part is the way it ties incremental change, fitness functions, connascence, architectural quantum, and database evolution into one operating model. That helps teams decide which constraints should be executable, where coupling has become too expensive, and how to change the system without losing delivery cadence.
In reviews and interviews, the chapter helps you discuss more than the target architecture. It gives you a way to explain how the design stays healthy after launch: which rules must be enforced, how degradation gets noticed, and why good architecture needs ongoing discipline.
Practical value of this chapter
Fitness functions
Shows how to convert architecture principles into measurable automated checks.
Controlled change
Helps roll out architecture changes incrementally without breaking delivery cadence.
Coupling visibility
Makes dependency hotspots visible before they become expensive change bottlenecks.
Interview differentiation
Strengthens interview answers with a practical strategy for keeping architecture evolvable.
Source
CoA Book Club
The chapter material is based on the book analysis in the Code of Architecture book club
Building Evolutionary Architectures, 2nd Edition
Authors: Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
Publisher: O'Reilly Media, Inc.
Length: 262 pages
Fitness Functions for Architectural Verification, Connascence, Architectural Quantum and Database Evolution.
Related book
Fundamentals of Software Architecture
Basic concepts of architecture: characteristics, styles, decision making
What is Evolutionary Architecture
Evolutionary Architecture = Incremental Change + Fitness Functions + Appropriate Coupling
Incremental Change
The architecture should support small, frequent changes instead of large releases
Fitness Functions
Automated checks of architecture compliance with specified characteristics
Appropriate Coupling
The right level of coupling between components for independent evolution
Related book
Continuous Architecture in Practice
Practical continuation of fitness functions: continuous feedback loops and architecture decisions as an ongoing process.
Fitness Functions
Fitness Function is an objective criterion for assessing how well an architecture meets a given characteristic. The term is borrowed from genetic algorithms.
Types of Fitness Functions
- Atomic — checking one characteristic (unit test)
- Holistic — checking the interaction of several characteristics
- Triggered — triggered by event (commit, deploy)
- Continuous — work constantly (monitoring)
Implementation examples
- Performance — load tests in CI/CD pipeline
- Security — SAST/DAST scanning, dependency audit
- Modularity — ArchUnit, dependency checks
- Resilience — Chaos Engineering experiments
Key idea
Fitness Functions integrate into the CI/CD pipeline and automatically block changes that violate architectural specifications. This turns architectural decisions into executable specifications.
Related book
Software Architecture: The Hard Parts
Detailed analysis of coupling, cohesion and architectural quantum
Coupling and Connascence
The book expands on the concept of coupling through the concept Connascence — a more detailed taxonomy of dependencies between components.
Static Connascence (weak)
- Name - name consistency
- Type - type consistency
- Meaning — consistency of semantics of constants
- Position — consistency of parameter order
- Algorithm — consistency of algorithms
Dynamic Connascence (strong)
- Execution - order of execution
- Timing - time dependencies
- Values - associated values
- Identity - links to one object
Rule: Strive for weak connascence between modules (Name, Type) and allow strong only inside the module. The stronger the connascence, the closer the components should be.
Architectural Quantum
Architectural Quantum — a minimal independently deployable artifact with high functional coherence, including all the necessary components (code, data, infrastructure) for operation.
Monolith
1 quantum = entire system
Modular Monolith
1 quantum, but logical separation
Microservices
N quanta = N services
Quanta quantity influences independence of evolution: the larger the quanta, the more independently parts of the system can develop, but the higher the operational complexity.
Related book
Database Internals
Deep dive into the DBMS design and distributed transactions
Evolution of Databases
Data schema evolution is one of the most difficult parts of evolutionary architecture. The authors recommend an approach incremental migrations.
ACID (RDBMS)
PostgreSQL, MySQL, Oracle
Strong consistency, schema fixed
BASE (NoSQL)
MongoDB, Cassandra, DynamoDB
Eventual consistency, flexible schema
NewSQL
Spanner, CockroachDB, YDB
ACID + horizontal scaling
Expand-Contract Pattern
For safe circuit evolution: Expand (add new field) → Migrate (transfer data) → Contract (delete old field). Allows you to make changes without downtime.
Organizational aspects
Architecture is inextricably linked with organizational structure (Conway's Law). The authors emphasize the importance of aligning architectural boundaries with team boundaries.
DORA Metrics
- Deployment Frequency - how often do we deploy?
- Lead Time for Changes — time from commit to sale
- Mean Time to Recovery — recovery time
- Change Failure Rate — % of unsuccessful deployments
Types of solutions
- Type 1 (irreversible) — choice of language, DBMS, cloud. Requires careful analysis.
- Type 2 (reversible) — API design, module structure. You can experiment.
Application at System Design Interview
✓ What to use
- Fitness Functions - “how will we check that the system complies with the SLO?” (monitoring latency, error rate)
- Architectural Quantum — justification of service boundaries and choice between monolith and microservices
- Expand-Contract — data schema migration strategy without downtime
- Connascence — analysis of dependencies between components during decomposition
✗ Common mistakes
- Design "for eternity" instead of an evolutionary approach
- Ignore the cost of future changes
- Ignore Organizational Constraints (Conway's Law)
- Choosing microservices without understanding operational overhead
Application example
"For this case I would choose modular monolith as a starting point - this gives one architectural quantum with low operational overhead. The boundaries of the modules correspond to bounded contexts, which will allow them to be extracted into separate services without refactoring in the future. As a fitness function for performance, we will add load test to the CI pipeline with threshold p99 < 200ms."
Verdict
Advantages
- A practical approach to architectural evolution
- The Fitness Functions concept is immediately applicable
- Good coverage of organizational aspects
- Synergy with other books by authors
Restrictions
- Fewer practical implementation examples
- Connascence may seem abstract
- Requires familiarity with other books in the series
Recommendation: Read after "Fundamentals of Software Architecture" and "Software Architecture: The Hard Parts" - the books form a trilogy with common terminology and complement each other.
Sources
Related chapters
- What is software architecture and why is it in System Design? - provides the architecture frame where evolution is treated as a continuous design activity, not a one-off refactor.
- Fundamentals of Software Architecture (short summary) - builds the baseline on characteristics and styles that fitness functions and evolutionary decisions rely on.
- Software Architecture: The Hard Parts (short summary) - extends the topic into hard distributed trade-offs: decomposition, data boundaries, and orchestration/choreography.
- Continuous Architecture in Practice (short summary) - shows how to operationalize architecture decisions and checks inside a continuous delivery loop.
- Evolutionary architecture in practice - adds a practical lens on incremental change, coupling management, and evolution triggers.
- Architecture at scale: how we make architecture decisions - translates the book ideas into organizational routines with RFC/ADR, decision logs, and governance.