Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Руслан Сафин - ArchDays 2023 (Рубрика Architecture)

Интересный и практичный доклад от Руслана Сафина на тему тестирования архитектуры. Основная логика доклада примерно такая

• Описываем архитектуру через plantuml в нотации C4 Model
• Все это сохраняем в репозитории в виде исходного кода (в той же репе, где хранятся конфигурации deployments для k8s)
• Дальше тестируем в пайплайнах соответствие нарисованного в plantuml и того, что лежит в настройках deployments (например, автор показывает как проверяется, что список сервисов в plantuml соответствует тому, что описано в деплойментах для k8s). Это позволяет поддерживать актуальность описанного в plantuml тому, что деплоится в реальности
• А вообще можно проверять тип и параметры связей, параметры деплойментов, соответствие конвенциям. Поэтому описываем базовые принципы нашей архитектуры и начинаем проверять их автоматически.

Руслан приводит следующие примеры принципов, которые они реализовали у себя

1. Использование ACL (anti-corruption layer) паттерна - сервисы, что реализуют ACL помечаем как adapter в plantuml, а дальше проверяем, что связи со внешними системами идут только через такие сервисы
2. Пассивные репозитории - репозитории предоставляют доступы только поверх БД, к ним могут быть входящие связи от сервисов, у них исходящие связи с базой, но вот исходящим связей к другим сервисам быть не может
3. Внешние вызовы должны идти через API Gateway - проверка по url в конфиге k8s и архитектурной диаграмме
4. Операции записи идут только через оркестратор бизнес-процессов (Kamunda)

Дальше можно накручиваать проверки и других принципов, которые вы приняли для себя (и зафиксировали в ADR). Ну и если находятся новые архитектурные проблемы, то можно написать еще новый тест и поправить потом проблему.

В конце доклада Руслан поделился тем, какие реально проблемы были решены

• Была актуализирована архитектура, а также приведена к конвенциям
• Были удалены устаревшие топики, куда только пушили сообщения, но не вычитывали
• Нашлись дубли внешних систем, которые были заведены в разных командах
• Получилось посчитать техдолг по количеству тестов и сервисов

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

P.S. Странно, что в самом начале доклада Руслан говорит о том, что об идеи о тестировании архитектуры никто не додумался. Этой теме очень много лет и про нее можно почитать книги, про которые я вспоминал раньше -- "Building Evolutionary Architecture" (первое издание 2017 года), в которой был концепт fitness function, но не было интересных примеров (я про нее рассказывал) -- "Software architecture metrics" (2022 год), где были примеры с архитектурными метриками (я про нее рассказывал) -- "Continuous Architecture in Practice" (2021 год), где была похожая история с тестами архитектуры (я про нее рассказывал)

Ну или почитать whitepaper пятилетней давности "Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles", о котором я рассказывал в прошлом году.

#Architecture #Software #SoftwareArchitecture #Management #Processes