Архитектурный репозиторий на базе 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
Интересный доклад Кирилла на тему архитектурного репозитория для компании среднего размера, в котором Кирилл рассказал про внедрение архитектурных процессов при росте компании. Основные мысли следующие
- При росте компании нужна формализация процессов проектирования
- Эта формализацию в небольшой компании может быть сделанна централизованно и для этого можно действовать пытаясь идти к подходам 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