Источник
Книжный клуб CoA
Материал главы основан на разборе книги в книжном клубе Code of Architecture
Building Evolutionary Architectures, 2nd Edition (Эволюционная архитектура. Автоматизированное управление программным обеспечением. 2-е межд. изд.)
Авторы: Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
Издательство: O'Reilly Media, Inc.
Объём: 262 страниц
Fitness Functions для проверки архитектуры, Connascence, Architectural Quantum и эволюция баз данных.
Оригинал
ПереводСвязанная книга
Fundamentals of Software Architecture
Базовые концепции архитектуры: характеристики, стили, принятие решений
Что такое Evolutionary Architecture
Evolutionary Architecture = Incremental Change + Fitness Functions + Appropriate Coupling
Incremental Change
Архитектура должна поддерживать небольшие, частые изменения вместо больших релизов
Fitness Functions
Автоматизированные проверки соответствия архитектуры заданным характеристикам
Appropriate Coupling
Правильный уровень связанности между компонентами для независимой эволюции
Fitness Functions
Fitness Function — это объективный критерий для оценки того, насколько архитектура соответствует заданной характеристике. Термин заимствован из генетических алгоритмов.
Типы Fitness Functions
- Atomic — проверка одной характеристики (unit test)
- Holistic — проверка взаимодействия нескольких характеристик
- Triggered — запускаются по событию (commit, deploy)
- Continuous — работают постоянно (мониторинг)
Примеры реализации
- Performance — load tests в CI/CD pipeline
- Security — SAST/DAST сканирование, dependency audit
- Modularity — ArchUnit, dependency checks
- Resilience — Chaos Engineering эксперименты
Ключевая идея
Fitness Functions интегрируются в CI/CD pipeline и автоматически блокируют изменения, которые нарушают архитектурные характеристики. Это превращает архитектурные решения в executable specifications.
Связанная книга
Software Architecture: The Hard Parts
Детальный разбор coupling, cohesion и architectural quantum
Coupling и Connascence
Книга расширяет понятие coupling через концепцию Connascence — более детальную таксономию зависимостей между компонентами.
Static Connascence (слабая)
- Name — согласованность имён
- Type — согласованность типов
- Meaning — согласованность семантики констант
- Position — согласованность порядка параметров
- Algorithm — согласованность алгоритмов
Dynamic Connascence (сильная)
- Execution — порядок выполнения
- Timing — временные зависимости
- Values — связанные значения
- Identity — ссылки на один объект
Правило: Стремитесь к слабой connascence между модулями (Name, Type) и допускайте сильную только внутри модуля. Чем сильнее connascence, тем ближе должны быть компоненты.
Architectural Quantum
Architectural Quantum — минимальный независимо развёртываемый артефакт с высокой функциональной связностью, включающий все необходимые компоненты (код, данные, инфраструктура) для функционирования.
Monolith
1 quantum = вся система
Modular Monolith
1 quantum, но логическое разделение
Microservices
N quanta = N сервисов
Количество quanta влияет на независимость эволюции: чем больше quanta, тем независимее могут развиваться части системы, но тем выше операционная сложность.
Связанная книга
Database Internals
Глубокое погружение в устройство СУБД и распределённые транзакции
Эволюция баз данных
Эволюция схемы данных — одна из самых сложных частей эволюционной архитектуры. Авторы рекомендуют подход инкрементальных миграций.
ACID (RDBMS)
PostgreSQL, MySQL, Oracle
Strong consistency, схема фиксирована
BASE (NoSQL)
MongoDB, Cassandra, DynamoDB
Eventual consistency, гибкая схема
NewSQL
Spanner, CockroachDB, YDB
ACID + горизонтальное масштабирование
Expand-Contract Pattern
Для безопасной эволюции схемы: Expand (добавить новое поле) → Migrate (перенести данные) → Contract (удалить старое поле). Позволяет делать изменения без downtime.
Организационные аспекты
Архитектура неразрывно связана с организационной структурой (Conway's Law). Авторы подчёркивают важность согласования архитектурных границ с границами команд.
DORA Metrics
- Deployment Frequency — как часто деплоим
- Lead Time for Changes — время от коммита до прода
- Mean Time to Recovery — время восстановления
- Change Failure Rate — % неудачных деплоев
Типы решений
- Type 1 (необратимые) — выбор языка, СУБД, облака. Требуют тщательного анализа.
- Type 2 (обратимые) — API дизайн, структура модулей. Можно экспериментировать.
Применение на System Design Interview
✓ Что использовать
- Fitness Functions — "как мы будем проверять, что система соответствует SLO?" (мониторинг latency, error rate)
- Architectural Quantum — обоснование границ сервисов и выбора между монолитом и микросервисами
- Expand-Contract — стратегия миграции схемы данных без downtime
- Connascence — анализ зависимостей между компонентами при декомпозиции
✗ Частые ошибки
- Проектировать "на вечность" вместо эволюционного подхода
- Не учитывать стоимость изменений в будущем
- Игнорировать организационные ограничения (Conway's Law)
- Выбирать микросервисы без понимания operational overhead
Пример применения
"Для этого кейса я бы выбрал modular monolith как starting point — это даёт один architectural quantum с низким operational overhead. Границы модулей соответствуют bounded contexts, что позволит в будущем извлечь их в отдельные сервисы без рефакторинга. В качестве fitness function для performance добавим load test в CI pipeline с threshold p99 < 200ms."
Вердикт
Преимущества
- Практичный подход к эволюции архитектуры
- Концепция Fitness Functions применима сразу
- Хорошее покрытие организационных аспектов
- Синергия с другими книгами авторов
Ограничения
- Меньше практических примеров реализации
- Connascence может показаться абстрактной
- Требует знакомства с другими книгами серии
Рекомендация: Читать после "Fundamentals of Software Architecture" и "Software Architecture: The Hard Parts" — книги образуют трилогию с общей терминологией и дополняют друг друга.