Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022 (Рубрика Architecture)

Интересный доклад Кирилла на тему архитектурного репозитория для компании среднего размера, в котором Кирилл рассказал про внедрение архитектурных процессов при росте компании. Основные мысли следующие

• При росте компании нужна формализация процессов проектирования
• Эта формализацию в небольшой компании может быть сделанна централизованно и для этого можно действовать пытаясь идти к подходам Arch as Code, который в версии Кирилла основан на следующих подходах и инструментах:
• Использование plantuml для описания диаграмм (фактически, это diagrams as a code) - я сам люблю этот инструмент для создания диаграмм. Он позволяет описывать диаграммы C4 Model и UML
• Использование Markdown для создания документации (из markdown можно генерировать в шагах пайплайна любые нужные вариации документации: сайт, pdf, ...)
• Использование Gitlab и TBD - собственно markdown документация и plantuml описания диаграмм лежат в коде (отсюда и название arch as a code)
• Процесс архревью выглядит как ревью изменения в архитектурном описании и получение аппрувов от нужных ребят: staff engineers, infra, security, etc

Дальше Кирилл интересно рассказывает про то, как выглядит их архитектурный репозиторий, который завязан на использование поддоменов из стратегических паттернов DDD и C4 Model для иерархического отображения архитектуры системы на разных уровнях абстракции. Интересно, что Simon Brown, создатель C4 Model, сделал свой инструмент для моделирования архитектуры - structurizr, где сначала идет описание модели системы, а потом можно делать разные view для разных целей (подробнее в моем посте)

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

• Domains -- Subdomains --- Teams ---- Services Дальше Кирилл рассказывает как эта вся машинерия работает, например, как заведены общие компоненты, как команды описывают свои сервисы и все такое. А дальше он переходит к описанию того, как в этом архитектурном репозитории пишутся и ревьювятся ADR (architecture decision records). Собственно при создании нового сервиса создается init ADR, в котором есть 3 части
• Описание проблема
• Ссылка на проведенный event storming (про который я уже как-то рассказывал раньше)
• Описание решения Плюс прикладываются основные диаграммы:
• Container diagram
• Component diagram
• ERD diagram
• Use case diagram При дальнейших ADR при изменениях системы описываются причины изменений + прикладываются диаграммы с diff было-стало, а также апдейтятся изначальные диаграммы. Все это проходит ревью, у которого есть SLA по скорости ревью (утверждается, что SLA выставлено в 2 дня). После аппрува это все мерджится в репозиторий.

В общем, я думаю, что этот подход может неплохо работать на масштабе нескольких сотен человек. Но у описанного подхода есть проблема - реальность архитектуры существует рядом с кодом, так как схемы рисуют отдельные люди в отдельной репе, а код пишут другие и в других местах. Насколько эти разные реальности близки - это большой вопрос. Но называть такой подход как architecture as a code я бы не стал - это скорее тянет на architecture documentation as a code:) Но это уже большой шаг вперед по сравнению с тем, как обычно в компаниях управляют архитектурой, так что если у вас нет ничего, то попробуйте внедрить что-то похожее.

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