Комментарии 8
Я, конечно, не архитектор, и статья не о том, но не стоит делать один общий микросервис для сотрудника и для клиента. Небезопасненько это. Например, DDоS по клиентскому каналу сломает UI для сотрудников.
Согласен, инструменты для записи диаграмм, а не их рисования для разработчиков определенно проще. Также удобнее хранить текст диаграмм в git, по ним можно получить внятный diff, так как формат PlantUML это несложный DSL. Пробовал внедрять в разных проектах и обычно успешно, не только разработчики, но и аналитики, техписы и даже менеджеры осваивают инструментарий и пользуются.
Как-то даже делал генерацию sequence diagram скриптом, PlantUML тем хорош, что можно куски описаний прям хоть в комментарии исходного кода положить, собирая из них потом потом общую картинку :)
Последнее время смотрю в сторону D2, как замены PlantUML. В D2 язык описаний выглядит более консистентным и единообразным для разных видов диаграмм.
Схожие темы:
В любом случае, "архитектурный репозитарий" нужно хранить в каком-либо формате.
Как и в каком формате хранить данные (логику) моделей? Архитектурные модели и данные о всех моделях компании и связях между моделями, атрибутами моделей, атрибутами объектов моделей. Модели процессов, структуры и иерархии процессов, организационных единиц, данных, документов и т.п. Да еще так, чтобы эти форматы были открытыми и «прозрачными».
Понятно, что речь не про формат Graphviz DOT (Mermaid, PlantUML и т.п.), т.к. это лишь промежуточное представление (синтаксические инструменты «обертывания» смысла в «цветные картинки»). Использовать реляционное (связанные таблички) представление данных модели, как это сделано во всех CASE\ BPMS системах, – это вариант постоянных экспортов \ импортов (ARIS XML) в закрытые проприетарные форматы каждой системы (ARIS Document format, ADF). Решением задачи может стать подход "Semantic BPM" (Semantic EA).
Темплейт для поднятия хоста с доками в C4 Structurizr и Arc42 - https://gitlab.com/plgrnd/aac
Я не читал первоисточников, но, кажется, всё-таки, что "архитектура как код" должна выглядеть так: текстовое описание определяет как (будет) развёрнута система. То что здесь я увидел, видится не более чем "документацией как код".
Как у вас устроен процесс версионирования as is и to be? Когда нужно одновременно иметь 2 диаграммы - для текущей ситуации и для, скажем, планового длительного рефакторинга, по итогу которого будут существенные архитектурные изменения.
Как правило, в каталоге domain/my-system мы держим актуальные на текущий момент описания и диаграммы, и если человеку нужно ознакомиться с as is, он идёт в текущие описания. В каталоге решений domain/changes содержатся описания доработок, и на странице конкретной доработки можно как раз найти диаграммы to be. Когда (и если) доработка попадает на прод, один из шагов финализации решения - это обновление текущих диаграмм в каталоге системы, чтобы as is стало to be.
Если предполагается совсем длительный рефакторинг, в несколько релизных циклов, и возникает необходимость прописать долгосрочную цель для широкого круга участников, то на нужной странице системы или её компонента размещается несколько схем с пометкой, что одна схема - as is, а другая - целевая архитектура, на которой отдельным цветом отмечены элементы, планируемые к внедрению в будущем.
Это касается главным образом контейнерных схем C4. Сиквенс-диаграммы живут только на страничке конкретных доработок.
Знания как код: архитектурный репозиторий в git на базе PlantUML