Раз архитектура — «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
Интересный и практичный доклад от Руслана Сафина на тему тестирования архитектуры. Основная логика доклада примерно такая
- Описываем архитектуру через 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