Эволюционная архитектура на практике

Инкрементальная разработка помогает быстрее проверять бизнес-гипотезы и уменьшает размер отдельной реализации. Но последовательность небольших изменений может постепенно запутать код и взаимодействие сервисов. Для одноразового прототипа это допустимо, если его действительно выбросят. Для системы, которую предстоит поддерживать, нужна проверка того, что быстрые итерации не разрушают свойства, на которых держится её дальнейшее развитие.

Автор связывает архитектуру не только с решениями, которые дорого изменить, но и с границами возможной траектории системы. Это делает важными доступность, сопровождаемость, проверяемость и другие характеристики качества. Их следует обсуждать вместе с функциональными требованиями: новая возможность приносит пользу лишь тогда, когда работает с требуемым качеством. Название «нефункциональные» не делает эти требования необязательными.

Фитнес-функции задают проверяемые границы для архитектурных характеристик. Они могут объединять разные виды тестов, метрики, наблюдение за работающей системой и оповещения. Сначала необходимо определить важные свойства и допустимые значения, затем автоматизировать проверку настолько часто, насколько возможно, в идеале при каждом изменении. Один успешно пройденный тест не доказывает пригодность всей архитектуры: нужна согласованная совокупность проверок.

В докладе приведены ArchUnit для проверок Java-кода, Danger для повторяющихся проверок изменений и внутренний инструмент Fitv. Последний появился при разделении монолита на десятки сервисов, чтобы контроль архитектурных правил не зависел исключительно от внимания технических лидеров. Такие инструменты помогают перенести известные ограничения в повседневный конвейер разработки, но сами правила по-прежнему должны отражать потребности конкретной системы.

Модульность рассматривается через внутреннюю связность и связи между компонентами. Принцип стабильных зависимостей направляет зависимости к более устойчивым компонентам; принцип стабильных абстракций связывает устойчивость с абстрактностью. Автор описывает две нежелательные крайности: трудноизменяемый компонент, привязанный к конкретной реализации, и абстракции, которыми никто не пользуется. Эти модели помогают обсуждать устройство системы, а не просто считать число сервисов.

Поводом для пересмотра архитектуры служат чрезмерный размер системы для одной команды, ухудшение поставки изменений и лишняя сложность окружения. Закон Конвея связывает эту работу с устройством взаимодействия людей. Поэтому изменение архитектуры может требовать изменения границ команд и платформенной поддержки. Практическое освоение подхода включает и изучение принципов, и решение реальных задач развития систем; одного знакомства с инструментами контроля недостаточно.