System Design Cases
Evolutionary Architecture: fitness functions, quanta, strangler fig
Evolutionary Architecture (Ford/Parsons/Kua, 2017, 2nd ed 2022): architecture supports guided incremental change. Fitness functions = automated checks of architectural characteristics in CI. Architectural quanta = independently deployable cohesive units. Strangler Fig pattern (Fowler) for legacy migration. Modular monolith ready for split. Topology: Repo + CI pipeline (lint, unit tests, architecture fitness via dependency-cruiser/ArchUnit, performance fitness via k6, security fitness via gitleaks/Snyk, API contract fitness via Pact, cost fitness via Infracost) -> gate -> canary -> production with continuous SLO + chaos engineering + auto-rollback. Includes Strangler Fig migration setup (facade, legacy, new service, shadow mode, feature flags) and modular monolith (catalog/orders/payments/billing modules with in-process bus) ready to split into 2 architectural quanta with own DB and Kafka. 4 scenarios: (1) fitness function fails CI on cyclic deps blocks PR; (2) Strangler Fig endpoint migration with shadow mode and gradual cutover; (3) modular monolith ready-for-split extracts payments quantum for PCI-DSS compliance without rewriting; (4) continuous + holistic fitness in production with auto-rollback on canary breach.
Evolutionary architecture: guided incremental change and fitness functions
Ford, Parsons, Kua и Sadalage определяют evolutionary architecture как guided, incremental change across multiple dimensions. Fitness functions делают важные characteristics проверяемыми, но не все качества сводятся к одному automated test. Evolutionary не означает хаотическое изменение и не превращает compliance, reversibility или loose coupling в гарантии.
Что утверждает паттерн — и чего он не гарантирует
- Evolutionary architecture supports guided, incremental change across multiple dimensions; guidance distinguishes it from uncontrolled emergence.
- Fitness functions can be tests, metrics and other verification; selection depends on characteristics and context.
- Reversibility is designed with compatible steps, telemetry, state migration and rollback—not granted by small commits.
- Compliance standards constrain outcomes/controls and scope; they do not universally mandate one service/database/network shape.
Границы и компоненты
| Компонент | Ответственность |
|---|---|
| Incremental Change Proposal | Описывает hypothesis, affected dimensions, blast radius и rollback. |
| Source, Schema and Configuration | Изменяются маленькими compatible steps. |
| CI Architecture Fitness Functions | Проверяют dependency, compatibility, security и other automatable constraints. |
| Runtime Fitness Signals | Измеряют SLO, errors, coupling proxies и recovery in operation. |
| Versioned Event Contract | Поддерживает compatibility/replay при incremental evolution. |
| Orders Consumer | Зависит от event contract и объявляет supported versions. |
| Analytics Consumer | Может обновляться независимо в пределах contract window. |
| Cardholder Data Boundary | CDE scope и data/process controls, не обязательный отдельный microservice. |
| Verified Segmentation Controls | Ограничивает paths to CDE и регулярно проверяется. |
| Decision and Rollback Ledger | Хранит hypothesis, evidence, checkpoints, ownership и reversal. |
Сценарии
Gate an incremental change
A proposal names latency, compatibility and dependency characteristics. CI checks automatable rules; review handles contextual trade-offs; rollout stays small and reversible.
Проверяемый исход: A failed fitness function blocks the step without claiming every architecture quality is machine-verifiable.
Evolve schema by expand and contract
Producer first supports old and new representation, backfills/validates, then consumers migrate before destructive contract.
Проверяемый исход: Rollback remains possible until compatibility and evidence gates expire.
Evolve an event contract
Producer publishes a compatible/versioned event through the broker contract; consumers dial the topic, declare support and migrate independently.
Проверяемый исход: No reverse duplicate topology edges or direct producer-to-consumer shortcuts; replay policy is explicit.
Verify a compliance boundary
Scope starts broad, data flows and connected systems are identified, and segmentation controls are tested. A separate service/DB may help, but PCI DSS does not uniquely prescribe that topology.
Проверяемый исход: Compliance claim is tied to verified scope and effective controls, not an architecture label.
Failure, concurrency и evolution checklist
- Set owner and response for every blocking/runtime fitness signal.
- Version contracts and retain replay/idempotency evidence through migration.
- Use canary/expand-contract/fencing for stateful changes; test rollback before contract.
- Re-scope CDE when data flow/connectivity changes and verify segmentation effectiveness.
Метрики, units и допущения
- A fitness threshold includes metric, unit, window and workload: for example error ratio over 10 minutes, not “fast enough”.
- Evolution step blast radius can be bounded by traffic percentage, tenant count or partition count and an explicit rollback time.
- Contract retirement uses observed consumer version/traffic over a declared window; zero observed traffic is evidence only within telemetry coverage.
Числа здесь — размерностные формулы или явно помеченные учебные inputs. Паттерн архитектуры сам по себе не задаёт SLA, throughput, latency или fault tolerance.
Связанные темы
[CONCEPT]architecture-decision-records
Первичные источники
- https://www.thoughtworks.com/content/dam/thoughtworks/documents/books/bk_building_evolutionary_architectures_second_edition_free_chapter.pdf
- https://www.thoughtworks.com/en-gb/insights/books/building-evolutionaryarchitectures-second-edition
- https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
Scope note
Fitness functions provide evidence within their measurement scope. They do not prove every emergent quality, organizational fitness, compliance outcome or reversibility under untested failure modes.