Архитектура ломается не только от плохих решений, но и от ложной идеи, будто все важное можно решить один раз в начале проекта. Эта глава показывает противоположный подход: архитектура живет внутри потока поставки и требует постоянной калибровки по мере изменений продукта.
Здесь особенно полезна сборка из quality attributes, delay decisions, маленьких инкрементов, governance и обратных связей, привязанная к реальному ритму поставки. Она помогает не отложить важные решения навсегда, но и не зацементировать их раньше, чем появился нужный контекст.
На интервью и в архитектурных review по этой книге удобно обсуждать процесс, а не только схему: какие решения нужно принимать рано, какие стоит задержать и как проверять архитектурные гипотезы прямо в цикле поставки.
Практическая польза главы
Continuous mindset
Переводит архитектуру из разового этапа в непрерывный процесс внутри delivery-цикла.
Quality attributes first
Помогает держать нефункциональные требования в центре решений, а не добавлять их постфактум.
Decision timing
Учит откладывать дорогие решения до достаточной информации, но не терять контроль над рисками.
Interview maturity
Показывает на интервью зрелый подход к архитектуре как к процессу, а не только к схеме.
Источник
Книжный клуб CoA
Материал главы основан на разборе книги в книжном клубе Code of Architecture
Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps
Авторы: Murat Erder, Pierre Pureur, Eoin Woods
Издательство: Addison-Wesley Professional
Объём: 352 страниц
6 принципов непрерывной архитектуры: от проектов к продуктам, quality attributes, delay decisions и архитектура для DevOps.
Связанная книга
Building Evolutionary Architectures
Fitness Functions, эволюция архитектуры и architectural quantum
6 принципов Continuous Architecture
6 принципов Continuous Architecture
Первый стрим: Главы 1–2
Глава 1: Why Software Architecture is More Important Than Ever
Архитектура в мире Agile, архитектура в облаке, роль архитектора как «не добавляющего ценность». Определение Continuous Architecture и набор принципов. Описание сквозного case study.
Глава 2: Architecture in Practice — Essential Activities
- Принятие и governing архитектурных решений
- Атрибуты качества и технический долг
- Циклы обратной связи: Fitness Functions, Continuous Testing
- Модели и нотации для описания архитектуры
- Архитектура как поток принятия решений
Гость стрима
Максим Смирнов — ИТ-архитектор, автор канала «Архитектура ИТ-решений». В прошлом главный архитектор билайна, Банка России и Бинбанк Диджитал.
Связанная книга
Learning Domain-Driven Design
DDD, Bounded Contexts, Event Sourcing и интеграционные паттерны
Второй стрим: Главы 3–4
Глава 3: Data Architecture
- DDD: Ubiquitous Language и Bounded Contexts
- Polyglot Persistence: SQL/NoSQL
- Модели консистентности и Eventual Consistency
- Event Sourcing
- Data Ownership и аналитика
- Эволюция схемы в SQL и NoSQL
Глава 4: Security as an Architectural Concern
- CIA триада: Confidentiality, Integrity, Availability
- Идентификация и приоритизация угроз
- Threat Modeling
- Shift-Left Security
- Zero Trust Architecture
Упомянутые материалы
Гости стрима
- Вацлав Довнар — независимый консультант по процессам безопасной разработки
- Дмитрий Гаевский — инженер dev-to-dev решений, RnD и event-driven систем
Связанная книга
Site Reliability Engineering
SLO, error budgets, мониторинг и четыре золотых сигнала от Google
Третий стрим: Главы 5–6
Глава 5: Scalability
Архитектурные подходы к масштабированию:
- Stateless нагрузки
- Stateful нагрузки
- Горизонтальное и вертикальное масштабирование
Глава 6: Performance
Производительность как архитектурная характеристика:
- Почему performance важна
- Мониторинг производительности
- Техники оптимизации
Упомянутые материалы
Гости стрима
- Алексей Тарасов — развивает архитектуру Тинькофф Инвестиций
- Даниил Кулешов — архитектор новой системы авторизации
Связанная книга
Release It!
Паттерны устойчивости: Circuit Breaker, Bulkhead, Timeouts
Четвёртый стрим: Главы 7–9
Глава 7: Resilience
Устойчивость как архитектурная характеристика. Паттерны: Circuit Breaker, Bulkhead, Retry, Timeout.
Глава 8: Emerging Technologies
AI и Blockchain — их влияние на архитектуру программного обеспечения.
Глава 9: Conclusion
Подведение итогов книги и рекомендации по внедрению Continuous Architecture.
Упомянутые материалы по Resilience
Гости стрима
- Евгений Пешков — техлид, основатель сообщества DDDevotion
- Сергей Баранов — архитектор, основатель конференции ArchDays
Источник
Telegram: book_cube
Пост Александра Поломодова о Resilience
Resilience как архитектурная характеристика
Базовая терминология
Fault (сбой)
Случайное условие, которое при возникновении может привести к отказу системы или её компонента.
Failure (отказ)
Ситуация, когда система отклоняется от требуемого поведения. Fault — причина, Failure — следствие.
Availability (доступность)
Измеримая характеристика: отношение времени доступности к общему времени работы системы.
Reliability (надёжность)
Вероятность безотказной работы за указанный период времени в указанном окружении.
High-Availability vs Resilience
Старый подход: High-Availability
- Кластеры приложений и баз данных
- Cross-site репликация данных
- Hot standby для аварийного переключения
Проблемы: сложность, высокая стоимость, долгий failover, полная недоступность во время восстановления
Новый подход: Resilience
- Каждая часть системы сама отвечает за устойчивость
- Адаптивное поведение при сбоях
- Ограничение распространения ошибок (blast radius)
Преимущества: гибкость, graceful degradation, быстрое восстановление отдельных компонентов
Ключевой инсайт: High-Availability был рассчитан на монолитные on-premise системы. Для распределённых микросервисных систем (on-premise или в облаке) Resilience — более подходящий подход.
MTBF vs MTTR
MTBF
Mean Time Between Failures
Среднее время наработки на отказ. Фокус High-Availability подхода: максимизировать время между сбоями.
MTTR
Mean Time To Recover
Среднее время восстановления. Фокус Resilience подхода: минимизировать время восстановления и blast radius.
Сдвиг парадигмы: В современных системах сбои частей происходят достаточно часто. Вместо попыток предотвратить все сбои (MTBF), важнее научиться быстро восстанавливаться (MTTR) и ограничивать влияние сбоев.
Механизмы обеспечения Resilience
Повторные запросы
Retry с exponential backoff
Автоматический перезапуск
Self-healing процессов
Circuit Breaker
Размыкание цепи при сбоях
Bulkhead
Изоляция отсеков системы
Timeout
Корректная работа с latency
Fallback
Запасные варианты ответа
Дополнительные ресурсы
Авторы создали сайт continuous-architecture.org с набором документов:
Связанные главы
- Что такое архитектура ПО и зачем она в System Design - задаёт общую рамку, где Continuous Architecture рассматривается как непрерывный процесс решений, а не отдельная фаза проекта.
- Building Evolutionary Architectures (short summary) - добавляет основу по fitness functions и управляемой эволюции, на которую опираются принципы непрерывной архитектуры.
- Эволюционная архитектура на практике - показывает прикладной слой: инкрементальные изменения, coupling и триггеры архитектурной эволюции в командах.
- Архитектура в масштабе: как мы принимаем архитектурные решения - раскрывает организационную сторону continuous-подхода через RFC/ADR, decision log и lightweight governance.
- Эволюция архитектуры Т-Банка (2006 -2025) - даёт длинный промышленный кейс, где видно, как переходят от проектного подхода к непрерывной архитектуре.