Архитектурные проверки в CI/CD
Читаю книгу O’Reilly «Современный подход к программной архитектуре: сложные компромиссы» (Нил Форд, Марк Ричардс).
Главная мысль, которая зацепила: архитектура - это не диаграммы и не разовые решения, а правила, которые должны проверяться автоматически.
Fitness functions
Авторы предлагают встраивать архитектурные проверки прямо в CI/CD - как тесты или security-сканы. Нарушили правило - пайплайн упал. Без ручного контроля и «договоримся потом».
Примеры из книги:
- Нельзя тихо ломать API - проверка контракта
- Нельзя смешивать домен и инфраструктуру - архитектурные тесты
- Нельзя выкатывать сервис без базовой готовности к проду - автоматические gate
Авторы называют такой подход fitness functions - функции пригодности архитектуры.
Простой вопрос
После подобных изменений архитектура станет лучше или хуже?
На практике видел мало команд, которые реально внедрили автоматические архитектурные проверки. Обычно всё заканчивается на уровне «договорённостей» и code review. А потом удивляются, почему через год монолит снова вырос внутри микросервисов.
Подход сложный, но правильный. Если CI/CD умеет проверять безопасность и покрытие тестами - почему бы не проверять архитектуру?
Читайте также
