Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023 (Рубрика Architecture)

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

• Кирилл начинает с постановки проблемы неактуальных схем и выделяет 4 момента: -- По неактуальной схеме невозможно принимать решения -- К неактуальной схеме низкое доверие у всех участников процесса разработки -- Сложно анализировать состояние системы тем, кому это нужно делать (аудиторы, участники процесса разработки) -- Такие схемы не помогают и во время operations - техподдержка и SRE не могут их эффективно использовать
• Для решения проблемы заводим архитектурный репозиторий, где с помощью C4 Model и подходов из DDD описываем свои сервисы (компоненты, из которых состоит наша система). Причем список компонентов должен вестись централизованно, чтобы мы могли их однозначно идентифицировать и переиспользовать внутри наших схем
• Для того, чтобы архитектурный репозиторий актуализировался автоматически нам требуется завязаться на наши конфигурационные данные о наших сервисах: -- Описание самого сервиса - в Sber Market это app.toml (конфигурация в формате TOML). Кстати, данные из этого файла используются для пополнения каталога сервисов, что используется для описания в архрепо -- Конфигурацию и зависимости сервиса - этот файл values.yaml используется для деплоя сервисов в production, поэтому он содержит актуальные параметры или сервис просто не будет работать как задумывалось в проде. Ну а для архитектуры можно использовать файлы из разных сервисов можно построить граф зависимостей для сервисов. -- Описание базы данных - в Sber Market это structure.sql, который содержит схему базы данных и может использоваться для составления ER-диаграмм.

В итоге, построение архитектурных диаграмм выглядит примерно так:

• Чтение файлов app.toml, values.yaml, structure.sql
• Преобразование данных из файлов к объектной модели
• Построение графа взаимосвязей для разных сервисов
• Рендеринг схем для всех сервисов - внутри сервиса есть ER-диаграммы, а также container диаграммы, на которые подтягиваются как сервисы в которые мы стучимся, так и те, что ходят к нам (они подтягиваются из values.yaml потребителей)
• Сохранение схемы
• Отображение схемы

В общем и целом, именно такой подход мне кажется правильным движением в сторону архитектуры как код:

• Использование стандартного тулинга для документации архитектуры
• Сама информация о сервисах и их взаимосвязах не заполняется руками, а тянется из системы, что является источником истины и определяет как наши сервисы задеплоены в реальности
• Поверх накручиваются тесты для контроля архитектурной целостности, что гоняются в пайплайнах (fitness functions из книги "Building evolutionary architecture")

P.S. На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать

• Архитектура как код - Роман Пионтик - ArchDays 2022
• Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022
• Материалы к моему докладу "Architecture at T-Bank: how we design our solutions"
• Раз архитектура — «as Code», почему бы её не покрыть тестами?!
• Проводим архитектурное ревью продуктовой фичи
• Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems