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.
Original
TranslatedRelated 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.