В быстро развивающейся системе архитектурные правила постепенно нарушаются. Как встроить автоматическую проверку архитектурных свойств в процесс поставки?
Используйте архитектурные fitness functions — автоматические проверки измеримых архитектурных свойств, которые запускаются вместе с обычным процессом сборки и поставки. Они могут контролировать направление зависимостей, допустимые границы модулей, время отклика, размер компонентов или независимость развертывания. Важно проверять не абстрактное соответствие диаграмме, а конкретное свойство с понятным критерием и реакцией на нарушение.
В традиционной разработке архитектура часто фиксировалась документами и начальными ревью. По мере изменения системы эти документы устаревали, а локальные решения постепенно создавали архитектурную эрозию.
Подход с fitness functions возник как практический способ поддерживать архитектурные характеристики в условиях непрерывной эволюции. Он переносит часть архитектурного контроля из ручных договорённостей в повторяемые автоматические проверки.
Архитектурное правило само по себе не защищает систему. Например, команда может договориться, что доменные модули не зависят от инфраструктуры, но новый компонент постепенно нарушит это правило ради более быстрого изменения.
Если нарушение обнаруживается только на большом ревью или во время масштабного рефакторинга, цена исправления возрастает. Кроме того, разные команды могут по-разному трактовать такие свойства, как независимость модулей или допустимая связанность.
Сначала архитектурное свойство переводят в проверяемый критерий. Например: модуль заказов не имеет зависимостей от пакетов инфраструктуры; публичный интерфейс модуля не превышает установленный набор операций; критический пользовательский сценарий укладывается в заданный предел задержки.
Затем выбирают способ измерения: анализ графа зависимостей, проверку структуры компонентов, тест взаимодействия, нагрузочное измерение или проверку метрик поставки. Проверка должна запускаться автоматически на подходящем этапе — от изменения проекта до интеграционного или нагрузочного контура.
Для каждого правила задают реакцию. Жёсткое нарушение может блокировать поставку, а отклонение с высокой неопределённостью — только создавать предупреждение и задачу на разбор. Это снижает риск, что неточный критерий начнёт блокировать полезные изменения и команды станут обходить сам механизм контроля.
Проверка должна быть связана с архитектурным решением и владельцем свойства. Иначе команда увидит красный сигнал, но не будет понимать, какое ограничение защищается, зачем оно нужно и кто принимает решение об исключении.
Fitness function не заменяет архитектурное мышление. Она проверяет выбранные признаки, но может не заметить неправильную бизнес-границу, чрезмерную сложность протокола или деградацию, которую ещё не выразили метрикой.
Основной компромисс — между полнотой контроля и стоимостью проверки. Слишком мало проверок не остановит эрозию, а слишком много хрупких проверок замедлит поставку и создаст ложное ощущение безопасности. Поэтому правила следует пересматривать вместе с архитектурой и удалять потерявшие актуальность ограничения.
Платёжную платформу развивали несколько команд. На архитектурной схеме доменная часть не должна была зависеть от адаптеров внешних платёжных провайдеров, но со временем в неё начали добавлять прямые вызовы провайдеров. Ручные ревью обнаруживали проблему уже после объединения изменений.
Рассматривались три варианта. Полагаться только на ревью было дёшево, но результат зависел от внимания конкретных людей. Полностью запретить любые изменения в спорной области было надёжнее, но резко снизило бы скорость разработки. Построить автоматическую проверку направления зависимостей с возможностью явно зарегистрированного исключения оказалось компромиссом.
Проверку включили в обязательный этап поставки. Нарушение блокировало изменение, а исключение требовало краткого обоснования, срока пересмотра и ответственного владельца. В результате новые нарушения стали обнаруживаться сразу, а архитектурная проверка превратилась из разовой активности в постоянное ограничение эволюции.
Архитектурный тест обычно проверяет конкретное структурное или поведенческое условие, например направление зависимостей между модулями. Fitness function — более широкое понятие: это автоматическая проверка архитектурного свойства, включая структурные, эксплуатационные и организационные характеристики.
Граница между терминами не всегда строгая. Существенно не название, а наличие измеримого критерия, регулярного запуска и понятной реакции на изменение результата.
Его следует разложить на несколько наблюдаемых признаков или использовать проверку как сигнал для ручного анализа, а не как безусловный блокирующий барьер. Например, качество границы можно оценивать сочетанием числа зависимостей, частоты совместных изменений и количества исключений.
Нельзя выдавать косвенную метрику за полное доказательство архитектурного качества. Иначе команда начнёт оптимизировать показатель, не улучшая саму архитектуру.
Проблема возникает, если правило устарело, допускает много ложных срабатываний или блокирует необходимые изменения без процедуры пересмотра. Тогда разработчики начинают отключать проверку, добавлять необоснованные исключения или выносить изменения за пределы контролируемого процесса.
Чтобы этого избежать, у правила должны быть владелец, назначение, срок пересмотра и прозрачный способ изменения. Автоматизация должна поддерживать архитектурные решения, а не превращать исторические ограничения в неизменяемые запреты.