Пост - публично поразмышлять письмом про методы описания архитектуры ИТ системы. Надеюсь на комментарии. Что-то вроде ADR по выбору подхода и инструмента.
Что меня натолкнуло написать этот пост? Последние несколько лет в среде ИТ архитекторов очень “горячей” темой является Architecture as a Code (как и много чего as a Code), немало докладов на конференциях в том числе от крупных компаний. При этом практически не слышно ничего про практики работы с табличками. Хочется сравнить эти подходы, посмотреть, что ограничивает применимость. Возможно просто про такой вариант просто мало информации в инфополе, а может и есть действительно подводные камни.
Какие смыслы вкладываются в слова “as a Code”:
- Документируем архитектуру в виде человеко-читаемого кода в текстовых файлах
- Используем системы контроля версий (git), причем желательно храним прямо вместе с тем кодом, архитектура которого описывается.
- Применяем все практики и инструменты работы с кодом - ветки, pull request, diff, merge, линтеры. Ветки используются для описания различных возможных путей развития системы, например вместе с отдельными ADR. Потом они могут приниматься или отвергаться, т.е. не быть приняты в текущий вариант архитектуры.
- Желательно генерировать по этому коду картинки, чтобы показывать другим ролям и доносить до них решения/изменения.
Распространенные представители - plantUML (отдельные view), structurizr (модель с разными view), C4 нотация в качестве модели.
В общем случае можно рассматривать как некоторый DSL для описания модели системы и разных view, что по сути и реализовано в structurizr.
В качестве альтернативы рассматривается подход с ведением табличек в productivity tools. Назовем его по аналогии с aaC = as a Code – itT = in the Table. Тут выделение отдельной запоминающейся аббревиатуры имеет значение для дальнейшей популяризации.
Есть также третий класс - более “тяжелые” Enterprise моделлеры, SparxEA, iServer, Archi (как наиболее “легкая” альтернатива). Заведомо не рассматриваются, но приведены для сравнения.
| EA Tools | Arch aaC | Arch itT | |
|---|---|---|---|
| Модель | Модель | DSL - Domain Specific Language | Структура табличек |
| Описание системы | Данные в модели | Код на DSL, файлы | Данные в табличках |
| Ветки (версии) | Ветки проектов | Ветки в Git | Тут не могу подобрать удобного варианта, гипотезы: 1. копия workspace c табличками 2. специальный артибут версии/ветки у каждой таблицы и строки, View на разные версии/ветки 3. генерировать из модели DSL и обратно, работать с DSL как с кодом через git |
| View | Встроенная визуализация модели, разные view | Генерация view по DSL инструментами “в комплекте” с DSL | Генерация view по данным из таблиц. Например, через тот же plantUML. Кстати AI с этой задачей неплохо справляется |
| Viewpoints | Viewpoints - как правило есть заложенные и возмодность определять свои | Есть заложенные viewpoints и способ расширять через DSL | Отдельные таблицы и их сочетания и являются viewpoints. Нет ничего готового, полный простор для деятельности. |
| Валидация | Встроенные правила и их расширения | Линтеры Возможно через AI | Формулы и прочие механизмы на конкретном productivity tool, возможна реализация стороними инструментами через API. Возможно через AI |
| Удобство работы | Обычно довольно тяжелые и сложные инструменты со сложным UI | Возможна поддержка DSL в IDE. Удобно для инженеров, для остальных есть картинки. | Довольно удобно заполнять, надо приноровиться читать. Генерация картинок также возможна. |
| Связь с управлением конфигурацией системы | Сложные интеграции с инструментом | Возможно, объем работ зависит от инструмента управления конфигурацией. | Очень легко добавлять и привязывать к архитектурной модели остальное управление конфигурацией в едином инструменте. |
В текущем проекте собираюсь использовать itT, собирать плюсы-минусы на практике.
Покритикуйте, что не учел, где может некорректное сравнение. И какие может быть есть мысли на тему - почему такого никто не использует или просто не рассказывает?