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.

Границы и компоненты

Сценарии

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

[CONCEPT]modular-monolith

Первичные источники

• 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.