Комментарии 10
А чем конкретно Structirizr не устроил?
Мы у себя внедрили, и, если его правильно приготовить, то он может очень многое.
Нельзя поправить диаграммы, они очень корявыми получались. Хочется, чтобы модели редактировались и в коде, и чтобы можно было подвигать фигуры на диаграмме при необходимости
Кроме C4 нам нужно много других моделей для описания требований, функциональных подсистем, сценариев использования, структур данных и т. д.
Не очень удобный интерфейс, хотелось древовидный навигатор по всем моделям и объектам
У Structurizr сложный тулинг. Как, например, генерить документы?.. И в целом это вещь в себе. Для инструментов моделирования есть много стандартов и готовых инструментов, а в Structurizr всё это игнорируется, у них свой формат хранения моделей, нельзя использовать готовые инструменты для генерации документов по этим моделям или для их анализа
Нет управления доступом к моделям. Что если проектов много? Хотя Structurizr модели можно хранить в Git рядом с кодом. Но хотелось бы централизованный архитектурный репозиторий
Хотелось бы описать архитектурные правила (для именования сущностей и связей, правила типа не больше N фигур и не больше M связей на диаграмме и т. д.) и потом валидировать по ним модели
В целом всё это наверное достаточно специфические требования. Я думаю, что есть много проектов, где Structurizr вполне норм
Так а там можно руками править. Автолейаут отключили, и вперёд.
Другие модели поддерживаются встроенными plantunl / kroki из коробки.
Правила натягиваются скриптами, поддержка которых есть, опять же, из коробки.
По остальному, наверное, более-менее соглашусь.
Точно можно править! Спасибо, я упустил этот момент или забыл уже
PlantUML всё равно не закрывает все требования. Например, нам нужны в модели данных платформо независимые типы (number, string,...) с разными параметрами (количество знаков после запятой, максимальная длина, шаблон для строки,...), чтобы потом по этим моделям генерировать SQL скрипты (при этом типы преобразуются в типы для конкретной СУБД — varchar, decimal,...), генерировать Java‑код (здесь типы будут заменяться уже на другие). Или нам для сущностей в модели данных нужно два названия (техническое на английском языке и на русском языке), чтобы можно было генерировать документацию
Или, например, для описания требований к системе в PlantUML нет нотации. Плюс PlantUML не позволяет двигать фигуры. Не позволяет делать межмодельные ссылки
С одной стороны, есть инструменты типа Structurizr, PlantUML и т. д., которые позволяют с минимальными усилиями закрыть требования. С другой стороны, есть более сложные инструменты моделирования типа Archi, Enterprise Architect, Rational Sofrtware Architect Designer и т. д. Мы хотим сделать что‑то среднее. Чтобы эта штука была простой и бесплатной, но по функциональности не сильно уступала Enterprise решениям
Да, и в конце концов, наличие аналогичных проектов для меня это скорее признак, что на такой продукт есть спрос, чем повод не делать этот проект, я уверен, что у нас во многом получится лучше
Еще Structurizr можно форкнуть, у него простой исходный код, и прикрутить что Саймон прикручивать не желает, например, arc42, превью и дополнительные АПИ. Для компаний делал импорт схем из баз данных и объектов из Кубера и Сворм кластеров. Двигать компоненты можно локально, координаты сохраняются и не пропадают при следующем импорте. Результат упаковывается в докер и релизится на сайт документации. Единственный минус Structurizr это рендеринг C4 на клиенте.
Очень интересно! А в какие модели импортировали схемы данных? В PlantUML? И что импортировали из Кубера? Модели для DevOps? Им эти модели были нужны, чтобы просто собрать информацию о своём ИТ ландшафте или потом они правили модели и что-нибудь генерировали из них?
Class diagrams PlantUML для схем. Кластеры, стеки/неймспейсы, ингресс, сервисы и сетевые политики из оркестратора в Structurizr DSL. Потребителей несколько - архитекторы, разработчики, SRE. Обновляются после деплоя. Так как это Architecture as Code, фитнесс функциями проверяется соответствие ADR, да и вообще удобно анализировать и встраивать вьюхи в Readme.
Пару лет назад рассматривали IcePanel, его два другана фаундера пилят. Но они заломили за enterprise несколько десятков тысяч долларов.
Ещё пара лет работы и получится IBM Rational Rose
Ну, как минимум, у нас уже есть одновременное редактирование моделей разными пользователями, управление доступом, API для интеграции с другими системами, не только диаграммные, но и текстовые нотации, no‑code конструктор для создания своих нотаций моделирования, плюс в целом веб‑интерфейс приятнее.
На мой взгляд мы уступаем IBM Rational Rose или аналогичным продуктам в количестве поддерживаемых нотаций. Реализовать полностью UML — не очень тривиальная задача, на это действительно может уйти много времени. Но вопрос нужен ли полный UML. Мы пока активно добавляем более простые нотации.
Другая вещь, в которой мы уступаем — это обилие всякого обвеса в виде кодогенераторов или наоборот инструментов для обратного инжиниринга. Но я уверен, что всё это не должно быть частью инструмента моделирования. Инструмент моделирования должен хорошо выполнять очень узкие задачи: редактирование, хранение, версионирование, валидация моделей, создание новых нотаций моделирования, возможно преобразование и анализ моделей. А всё остальное может работать через API. У нас цель сделать не многофункциональный комбайн, а очень простой инструмент, который решает узкую задачу, но делает это максимально хорошо
Сделали свой редактор C4 моделей