Evolutionary architecture
Evolutionary architecture is the design approach that explicitly plans for architectural change over time — building in fitness functions, modular boundaries, and incremental migration paths so the architecture can evolve without big-bang rewrites. The alternative — 'final' architecture — typically ages badly and produces rewrite cycles.
The discipline's central claim is that change is the only architectural constant, so design for change should be a first-class concern. Evolutionary architecture has three components: fitness functions (encoded architectural rules that catch drift), modular boundaries (small, well-defined units that can be replaced individually), and incremental migration patterns (strangler fig, parallel run, feature flags). The pattern is most relevant for long-lived systems where the original assumptions will not hold for the system's lifetime. The trap is over-engineering for change that doesn't happen; the discipline is to design for the changes likely in the next 2-3 years, not every conceivable future.
Discussed in our use-cases
ICP-targeted pages where evolutionary architecture is part of the framing.
Related terms
- Architecture fitness function
An architecture fitness function is an executable test that asserts an architectural characteristic — coupling between modules, cyclic-dependency absence, response-time budget, dependency direction.
- Strangler fig pattern
The strangler fig pattern is a migration approach for legacy systems: instead of replacing the system in one big-bang cutover, incrementally route specific functionality to a new implementation while the old system continues to run.
- Modular monolith
A modular monolith is a single deployable application internally organised into well-defined modules with explicit boundaries, typed contracts between modules, and independent ownership.