Комментарии 21
Роль Владельца смежной системы — самая тонкая. Как вы обеспечиваете агента актуальным контекстом (RAG) о соседних сервисах? Ведь если агент не "видит" API соседа в реальном времени, он выдаст галлюцинацию о том, что "всё совместимо", а на интеграционном тесте всё упадет. У вас есть единая векторная база данных (Knowledge Base) всей корпоративной архитектуры?
Сейчас решаем эту проблему только частично - вручную подкладываем спецификации смежных систем в соответствующую папку input. Агент учитывает документы из неё при генерации арх. решения и при ревью.
Но согласен с вами, следующий шаг должен быть в автоматизации этого процесса.
У нас в компании есть корпоративная База Знаний для Искусственного Интеллекта (БЗИИ) и реализован RAG по ней. В том числе, там есть статьи из корпоративного Confluence со спецификациями систем. Плюс, сейчас в разработке корпоративные MCP сервера по Confluence и Jira. Эти сервисы можно подключить как тулы к Claude Code и тогда агент сможет искать релевантную документацию и получать полный текст статей.
Это в планах есть.
Согласна, ручной input — это всегда риск потери актуальности, особенно в динамичных системах (привет 1С и ERP). Но круто, что смотрите в сторону MCP‑серверов и автоматизации RAG через Confluence. Это действительно единственный путь сделать агента «зрячим» в реальном времени. Буду следить за вашими успехами в этом направлении, тема архиважная!
Респект, решение не от вайбкодера. Было бы полезно добавить в репу файл с бизнес - требованиями, чтобы можно было сразу что-то сгенерировать.
А такого рода моделях или языках описания много недостатков.
Structurizr - почти нет поведения, чистая структура. Все существующие архитектурные DSL по сути декларативные описания: boxes and arrows.
А в реальности у архитектурной модели есть правила:
если поток несет ПДн, автоматически требуется шифрование канала и запись в раздел ИБ
если система внешняя, нужен API Gateway
если добавляешь новый контейнер, он должен попасть в реестр, получить код, владельца
если два контейнера в разных контурах безопасности - нужен межсетевой экран
Это бизнес-логика архитектурного процесса. Ни один существующий DSL это не покрывает. Поэтому все и делается руками - архитектор держит правила в голове и применяет при оформлении.
По сути нужна не схема как код, а архитектурная модель как программа - с валидацией, выводом, правилами. Ближайшая аналогия - не Mermaid, а скорее что-то вроде OPA/Rego поверх модели, или доменная модель в духе Влашина - make illegal states unrepresentable, но для архитектуры.
Такого готового инструмента я не знаю.
Нагрузка, латентность, бюджет, размер команды, time-to-market, объем данных. Это не булевы правила, а trade-offs - они влияют на выбор между вариантами.
Тут умная модель уже не просто валидирует, а помогает принимать решения. Условно: при <1000 RPS монолит допустим, при >10000 нужен горизонтальный масштаб, а между - зависит от других факторов.
Это уже была бы система поддержки принятия решений, не просто DSL. Decision framework поверх модели. Это ровно то знание, которое архитектор накапливает годами и носит в голове. Формализовать его целиком невозможно - слишком много контекста. Но типовые паттерны выбора ("при таких НФТ обычно делаем так") вполне кодируемы.
А пока что архитектура как код это только для отслеживания diff и то плохо. Версионирование, review process, автоматизация генерации документов - это реальные плюсы. Но без семантической модели с правилами это просто текстовый формат вместо Visio. Удобнее хранить в git, но суть та же - ручная работа архитектора, просто в другом формате.
Спасибо за развёрнутый комментарий! У Structurizr DSL действительно есть ограничения. В первую очередь он про описание структуры, в нём ничего нет про логику и правила.
Но именно об этом и статья: о том как LLM позволяет преодолеть ограничения DSL.
В нашем подходе логика, правила, стандарты, шаблоны переносятся в слой инструкций к LLM-агенту. По сути, мы создаём тот самый Decision framework поверх модели на DSL, о котором вы пишете, только не на жестком языке типа OPA/Rego, а на естественном языке промптов. Цель не в том, чтобы полностью перенести знания из головы архитектора - а в том, чтобы описать типовые правила и снять рутину. Постепенно определить, стандартизировать и описать самую критичную логику и ограничения вполне возможно.
И здесь есть ещё один важный эффект: когда правила описаны явно - в промптах, в документах, в примерах - они становятся общими для всей команды. Когда на ландшафте работает 5-10 архитекторов, каждый со своим опытом, знаниями и представлениями о правилах в голове, это особенно ценно.
В нашем репозитории эти правила живут в нескольких местах:
CLAUDE.md - общие инструкции для проекта: стиль именования, структура репозитория, общие принципы.
Файл скилла SKILL.md - инструкции к конкретному сценарию. Здесь описывается логика: что проверять, какие разделы генерировать, какие правила применять.
Директория docs - стандарты ИБ, требования корпоративной архитектуры, шаблоны. LLM читает их и добавляет в контекст.
Директория solutions - примеры уже согласованных арх. решений. LLM распознаёт паттерны внутри них и применяет к новому решению.
Также в Structurizr DSL мы можем помечать элементы и связи метаданными через теги и properties. На основе этих метаданных LLM может понимать, какие правила нужно применить.
Как бы я решал описанные вами кейсы в нашем подходе:
Если поток несет ПДн - нужно шифрование и запись в раздел ИБ
В DSL на поток вешается тег "PDn". В инструкции скилла прописываем правило: "Проверь все связи с тегом PDn. Если протокол не TLS/mTLS - ошибка валидации. Если тег есть, убедись, что этот поток упомянут в разделе ИБ документа".Если система внешняя, нужен API Gateway
Внешние системы в модели уже помечены тегом External. В скилле прописываем правило: все связи от систем с тегом External к внутренним контейнерам должны идти через API Gateway.При добавлении нового контейнера, он должен попасть в реестр, получить код, владельца
Прописываем в скилл инструкцию: "для каждого нового контейнера заполни properties: code, owner и т.д. и создай запись в реестре; если увидишь контейнер без этих свойств - ошибка валидации".Два контейнера в разных контурах безопасности - нужен межсетевой экран
Для контейнеров прописываем property securityZone=zoneA/zoneB. В скилле пишем инструкцию "Если связь пересекает разные контуры безопасности, добавь запись в таблицу межконтурного взаимодействия".
Да, это не формальная система с гарантиями валидации - LLM может ошибаться, и архитектор всё ещё должен проверять результат глазами. Но роль архитектора всё больше смещается: от создания с нуля к ревью.
Описанный подход работает на наших кейсах - тех, что в статье. Попробуйте, может сработает и на ваших.
Занятно...
Надо подумать
А у меня кейсов нет. Я теоретик. Обучился на архитектора, но что-то не тянет... Из-за слишком большой доли личных коммуникаций и вкусовщины, причем не меня а начальника.
Алексей, спасибо, за статью. Подскажите, пожалуйста, нет ли у вас проблем с качеством/переполнением контекста при использовании данного подхода? Или вы управляете наполнением docs/ skills.md под конкретную задачу?
И с тем, и с другим бывают проблемы. Субъективно, по качеству Opus значительно лучше Sonnet. И за той, и за другой моделью иногда приходится руками код править.
Контекст тоже периодически переполняется, это проблема. Здесь есть общий (для агентов) тренд - уходить от заполнения огромного CLAUDE.md к специфичным скиллам и специфичным документам в docs. Это помогает, т.к. инструкции из CLAUDE.md подгружаются в контекст всегда, а из скилла только при вызове этого скилла. Соответственно, скилл уже выбирает, какие документы из docs подгрузить для выполнения своих функций.
То есть, вместо написания 10 строк dsl используем llm?
Про dsl всё прекрасно, но зачем ии тут?
Вам же написали, для
Ускорение в 2+ раза
В наших кейсах 10 новых строк на dsl могут приводить к необходимости заполнить 10-ти страничный документ с обязательными разделами, таблицами и данными.
Также эти 10 строк должны быть написаны в соответствии со стандартами и результат должен быть провалидирован.
Всю эту рутину вместо вас может сделать ии.
Самое ценное тут не скиллы а validate-dsl.sh в цикле. Треть генераций невалидна - агент по сути берёт количеством попыток. Тот же паттерн работает с terraform и k8s манифестами - если у DSL есть нормальный валидатор, LLM справляется. Если нет - бесполезно
Structurizr Lite уже переведён в архив. BPMN как вход тяжело анализируется. Мы попробовали вместо него Event Storming Diagram. Ограниченный контекст собирается лучше, в значит упрощается прыжок в C4
Пора обновляться на LikeC4.
Вы знали, что с помощью LLM можно вывести подход Architecture as Code на новый уровень?