Система редко превращается в неуправляемую за один релиз. Сегодня один модуль напрямую обращается к чужой таблице, завтра второй получает лишнюю зависимость, через месяц критический маршрут начинает заметно тормозить. Каждый локальный шаг можно оправдать. В сумме границы архитектуры постепенно исчезают.
Architecture Fitness Functions — это проверяемые правила о свойствах системы. Они помогают замечать отклонение не на позднем совещании, а рядом с моментом изменения.
Сначала решите, какое свойство защищать
Например, команда договорилась, что модуль платежей не должен напрямую зависеть от интерфейсного слоя. Такое правило можно проверить анализом зависимостей в CI. Или у важного сценария есть допустимый уровень задержки — его можно наблюдать в тестах и эксплуатации.
Это разные виды проверок. Одни проверяют исходный код, другие — поведение живой системы. Не стоит выдавать успешный запуск статического анализатора за доказательство надёжности платежей.
Когда автоматическая проверка действительно окупается
Она полезна там, где нарушение правила повторяется, его трудно заметить при ревью и последствия существенны. Например, прямой доступ нескольких сервисов к чужой базе может постепенно разрушать возможность независимых изменений.
После формулировки границы тест может отклонять новые недопустимые зависимости или хотя бы сигнализировать о них до выпуска. Так архитектурное решение перестаёт зависеть от памяти одного человека, который когда-то нарисовал схему.
Проверки могут заморозить плохое решение
Но ограничения стареют. Иногда правило создаёт ложные срабатывания, мешает необходимой миграции или защищает архитектурный выбор, который бизнес уже должен пересмотреть.
Поэтому у проверки нужен владелец, описание смысла, способ временного исключения и периодический пересмотр. Иначе команды начнут обходить тесты, а затем отключат их целиком.
Не всякое архитектурное качество легко измерить. Простоту понимания бизнес-процесса и ясность ответственности нельзя свести к одному числу. Автоматизация дополняет обсуждение, но не заменяет его.
С чего начать без большой программы
Я бы взял одну границу, нарушение которой уже дорого обходилось команде, и сделал её наблюдаемой. Проверил бы, действительно ли сигнал ведёт к полезному действию, а не просто добавляет красный значок в пайплайн.
Решение и причины его появления удобно зафиксировать в ADR, а конкретное свойство — проверять автоматикой.
Fitness Function полезна тогда, когда предотвращает дорогую деградацию. Если никто не знает, зачем правило существует и что делать при нарушении, это уже не защита архитектуры, а техническая бюрократия.