Архитектурный контроль в эпоху агентной разработки: MDM, графовая верификация и open-source BeeAtlas

Небольшой контекст

• AI-агент может предложить правдоподобную, но ложную архитектуру: несуществующий сервис, запрещённую технологию, лишнюю связь между микросервисами.

• Мы исходим из того что архитектура всё чаще хранится в Git как код (workspace.dsl), а не в Confluence-картинках. В статье я буду ссылаться на один из самых распространенных подходов по ведению архитектуры — Structurizr DSL.

• Знание Cypher и Neo4j вам не обязательны, если вы только правите DSL; они нужны тем, кто пишет корпоративные правила и паттерны.

---

Аннотация

Агентная разработка — IDE-агенты, Copilot, MCP-инструменты — ускоряет написание кода и архитектурных описаний. Файлы Structurizr DSL, OpenAPI и ADR появляются быстрее, чем их успевают проверить. В результате растёт «шум» в моделях: LLM рисует убедительные, но выдуманные контейнеры, связи, технологии и коды возможностей.

Устойчивый контроль строится на трёх опорах:

1. Архитектурный MDM — единый справочник: какие системы, технологии и связи считаются каноническими (source of truth для людей и агентов).

2. Графовая верификация — автоматическая проверка связей между сервисами (циклы, единые точки отказа и т.д.).

3. Architecture as Code — текстовая модель в Git + проверки в CI при каждом push.

4. Enterprise — Все описанные практики применимы в больших компаниях с разнородным ИТ-ландшафтом. Если у вас небольшой pet-проект, то и с описанными проблемами вы вряд ли столкнетесь.

В статье показано, как это реализовано в BeeAtlas и как поднять open-source стек beeatlas-fdm-infrastructure.

---

1. Почему архитектура не успевает за агентами

Раньше узким местом было написание кода. Сегодня — проверка того, что агент предложил. За минуты он добавляет контейнер в workspace.dsl, дописывает sequence-диаграмму, генерирует OpenAPI и черновик ADR (Architecture Decision Record — запись об архитектурном решении). Merge request уходит в Git до того, как кто-либо сверил модель с реальным ландшафтом компании.

Три риска становятся системными.

• Объём. Сотни приложений, тысячи записей в каталоге возможностей, десятки репозиториев с моделями. Ручной обход схем нереалистичен.

• Скорость устаревания. Модель в Git отстаёт от прода через неделю. Агент, опираясь на устаревший контекст, усугубляет рассинхрон.

• Галлюцинации моделей. LLM «додумывает» архитектуру: выдумывает возможности ландшафта, указывает технологию вне белого списка, рисует связь между сервисами, которые не интегрированы. Без внешнего якоря текст модели похож на правильный, но ложен.

Классический архитектурный надзор (экспертные сессии, чек-листы) остаётся ценным для крупных решений, но не масштабируется на еженедельный поток изменений. Ручной аудит плохо ловит топологические дефекты — ошибки в связях, а не в коде:

• Циклические зависимости — A → B → C → A: при изменении любого сервиса приходится перекатывать все.

• Единая точка отказа — один сервис держит на себе половину системы; упал он — упало всё.

• Скрытое совместное размещение — независимые продукты на одном сервере: падение хоста приводит к падению обоих продуктов.

Вопрос статьи: как встроить объективный контроль в pipeline, не замедляя агентов?

Ответ: не ещё один репозиторий картинок, а управляемый архитектурный ландшафт с машиночитаемыми правилами.

---

2. Кейс: агент предлагает новый микросервис

Сначала история — потом теория.

Команда в Cursor с MCP-доступом к каталогу архитектуры. Задача: «выделить сервис нотификаций из монолита». Агент добавляет в workspace.dsl:

...notification = container "Notification Service" {    technology "Aerospike"}order.api -> notification "Отправка события заказа" "HTTP"...

CI на этапе fitness_check отвечает:

TECH.01 FAILED — технология "Aerospike" запрещена в техрадаре компанииTECH.03 FAILED — используются недопустимые протоколы взаимодействия "HTTP"

Разработчик (или агент по тексту ошибки) исправляет модель: меняет HTTP на HTTPS, меняет Aerospike на Redis из категории Adopt техрадара. Фитнес-функции проходят.

Дальше срабатывает графовая проверка: найдена циклическая зависимость сервисов order-service ↔ notification-service ↔ billing-service ↔ order-service. Агент переносит интеграцию на брокер сообщений; цикл устраняется.

Мораль: агент генерирует гипотезу, CI и граф её верифицируют — как тесты для кода. Подсвечиваются архитектурные ошибки и агент их исправляет.

---

3. Архитектурный MDM: единый справочник

3.1. Что это простыми словами

MDM (Master Data Management) в контексте архитектуры — не бюрократия, а канонический реестр, на который опираются команды и инструменты. Аналогия: как npm registry для пакетов, но для архитектуры компании.

Минимум, который должен понимать разработчик:

Платформа BeeAtlas реализует этот справочник в связке с корпоративным стандартом описания технических решений. Метамодель задаёт обязательные поля — технология из техрадара, код technical capability, используемые business capability, URL репозитория. Это контракт, который CI может проверять автоматически.

Например, у каждого контейнера в модели обязательно должны быть:

• technology — технология из техрадара (проверяется TECH.01)

• url — ссылка на репозиторий в GitLab (проверяется GIT.01)

А у каждого приложения — cmdb (короткий код в IT-учёте). Без этого модель просто не пройдёт CI.

3.2. Что это значит для разработчика

В вашем репозитории лежит текстовый файл архитектуры workspace.dsl (на самом деле, файлов может быть много, так как Structurizr поддерживает включение файлов через !include). При push:

1. CI запускает фитнес-функции — автопроверки, как eslint для схемы.

2. При ошибке вы видите код (TECH.01, CPB.03) и описание — исправляете DSL, как код после упавших тестов.

3. Агент с доступом к каталогу не выдумывает коды BC/TC и технологии — читает их из справочника.

Минимальный контур для dev: Git + workspace.dsl + CI fitness_check.

Enterprise-контур (настраивают архитекторы и админы платформы): каталог корпоративных возможностей, техрадар, BPM-согласования для ‘human in the loop’, MCP gateway, интеграция с CMDB.

3.3. MDM как якорь для агентов

Без справочника агент галлюцинирует контекст. Со справочником он может:

• запрашивать существующие BC/TC;

• сверять технологии с техрадаром;

• находить связанные приложения для интеграции;

• читать паттерны и нефункциональные требования (НФТ).

В open-source стенде BeeAtlas:

• API Gateway — единая точка входа к сервисам каталога;

• MCP gateway — сервер, через который Cursor и другие агенты читают архитектурный контекст извне;

• WebIDE + плагин C4 Architecture As A Code — редактирование Structurizr DSL с подгрузкой возможностей из BeeAtlas в Visual Studio Code / Cursor.

3.4. Architecture as Code вместо «рисования»

Диаграммы в draw.io быстро устаревают. Architecture as Code — архитектура в текстовых файлах (Structurizr DSL): одна модель порождает контекстные, контейнерные и deployment-диаграммы. Модель в Git, code review, CI.

Мини-пример: из этого фрагмента генерируются все диаграммы C4:

c4model

workspace "Мой сервис" {    model {        user = person "Пользователь"        system = softwareSystem "Order Service" {            properties {                cmdb ORDER_SVC            }            api = container "API" { technology "Spring Boot" }            db  = container "БД"  { technology "PostgreSQL" tags "Database" }        }        user -> system.api "Использует"        system.api -> system.db "Читает/пишет" "TCP:5432"    }}

Связь с ландшафтом: модель привязывается к уникальному коду программной системы (например, его можно взять равным коду в вашей CMDB системе), capability-компоненты получают коды технических возможностей, а после прохождения CI публикация попадает в каталог. После этого все знают, что ваша система может делать и как с ней интегрироваться.

---

4. Графовая верификация — ответ на галлюцинации

4.1. Сервисы и стрелки

Ошибки LLM в архитектуре — это ошибки структуры: лишние стрелки, несуществующие узлы, технологии вне белого списка, циклы. Их можно проверить изучив архитектуру отдельной системы. Однако, в больших компаниях нам нужно посмотреть как система встраивается в общий ландшафт и влияет ли она на его нефункциональные свойства (в первую очередь на надежность).

Архитектуру удобно представить как граф: сервисы = узлы, вызовы и зависимости = стрелки. Вопросы «есть ли цикл?», «какой сервис держит всё на себе?», «какие системы сидят на одном хосте?» — это запросы к графу. Для них подходит графовая СУБД Neo4j; язык запросов Cypher — по смыслу SQL для связей.

Подробнее для архитекторов: почему не model checking

Формальная верификация (model checking, temporal logics) хорошо работает с поведением системы, но плохо масштабируется на топологию ландшафта из сотен сервисов. Нам нужен структурный анализ с локализацией проблемного узла, а не бинарный ответ «свойство нарушено».

4.2. Шесть автоматических проверок «здоровья» архитектуры

Метод разработан в выпускной квалификационной работе Почечуры А.А. (подробнее — в разделе «Благодарности»). Суть: модель Structurizr (JSON) → граф в Neo4j → проверки на Cypher и алгоритмах Neo4j GDS (Graph Data Science).

Каждая проверка возвращает список конкретных узлов — не абстрактный fail, а адрес проблемы для исправления в DSL.

4.3. Паттерны и антипаттерны: Cypher как язык архитектурных правил

В BeeAtlas графовый анализ дополняется паттернами — проверенными решениями типовых задач, и антипаттернами — типичными ошибками. Каждый паттерн содержит правило идентификации — Cypher-запрос к архитектурному графу.

Как это работает:

• В правиле используется подстановка {cmdb} — при проверке она заменяется на код конкретного приложения

• Если запрос возвращает результат — паттерн выполнен

• Если ничего не вернул — не выполнен

Пример. Паттерн «Базы данных PostgreSQL и MySQL только во внутреннем сегменте»:

cypher

WITH 1 AS _ WHERE NOT EXISTS {  MATCH (ss:SoftwareSystem)-[:Child]->(c:Container)-[:Deploy]->(ci:ContainerInstance)<-[:Child]-(dn:DeploymentNode)  WHERE toLower(toString(ss.cmdb)) = '{cmdb}'    AND ((c.technology CONTAINS 'PostgreSQL') OR (c.technology CONTAINS 'MySQL'))    AND ((dn.external_ip IS NOT NULL AND trim(toString(dn.external_ip)) <> ''))} RETURN 1;

Этот запрос проверяет, что ни одна база данных приложения не имеет внешнего IP. Если нарушение найдено — паттерн не выполнен, архитектор получает уведомление.

Что важно: Cypher-правила можно генерировать через LLM. В документации BeeAtlas есть готовый системный промпт, который описывает модель графа и формат запроса. Достаточно сказать «напиши правило, которое проверяет, что все Kafka-топики имеют retention > 7 дней» — и LLM сгенерирует корректный Cypher.

4.4. Аналитический отчёт: кто не проходит проверки

Все результаты проверок собираются в аналитический отчёт фитнес-функций — матрицу «домен × приложение × правило». Это не разовый аудит, а живой дашборд:

• Зелёный — проверка пройдена

• Красный — есть нарушения, нужно исправлять

• Жёлтый — частичное соответствие

Архитектор домена открывает отчёт раз в спринт и видит, какие приложения отстают. Можно экспортировать в Excel и поставить задачи командам.

4.5. Контур работы

---

5. BeeAtlas — open-source платформа архитектурного контроля

Весь стек доступен на GitHub: tech-beeline/beeatlas-fdm-infrastructure (Apache 2.0).

Что входит

Для эксперимента не обязательно поднимать всё. Достаточно: UI + gateway + Neo4j + architect-graph-service + capability-backend + products-service. Остальное — полный корпоративный контур (BPM, документы, уведомления).

Как это связано с ВКР

architect-graph-service — промышленное развитие методов графового анализа из ВКР Почечуры А.А. ВКР дала академическую формализацию и прототип, BeeAtlas добавляет MDM, фитнес-функции, паттерны и организационные процессы.

API Gateway: интеграция для своих скриптов и CI

У BeeAtlas есть API Gateway с HMAC-аутентификацией. Можно программно:

• создавать продукты и технологии

• загружать контейнеры и интерфейсы

• получать BC/TC из ФДМ

• проверять статусы фитнес-функций

Полная OpenAPI-спецификация — в репозитории beeatlas-doc.

---

6. Как развернуть и адаптировать

6.1. Быстрый старт

Требования: Docker 20.10+, Compose v2, Git.

bash

git clone --recurse-submodules https://github.com/tech-beeline/beeatlas-fdm-infrastructure.gitcd beeatlas-fdm-infrastructuredocker compose -f docker-compose-run.yml pulldocker compose -f docker-compose-run.yml up -d

Логин в UI: Authentik (akadmin, пароль в docker-compose.yml). API на локальном стенде — demo-режим без JWT.

6.2. Что вы увидите после запуска

1. Заходите в UI (http://localhost:3000) — перед вами каталог моделей

2. Открываете Каталог приложений — пока пусто, но можно загрузить первый workspace.dsl

3. Загружаете архитектуру через WebIDE или кнопку «Загрузить версию архитектуры»

4. После публикации — граф зависимостей в Neo4j Browser (http://localhost:7474)

5. Отчёт фитнес-функций — матрица проверок для ваших приложений

6.3. Сценарий разработчика

1. Клонировать репозиторий продукта с workspace.dsl (или взять шаблон из документации BeeAtlas).

2. Установить Structurizr Lite локально или плагин C4 Architecture As A Code в VS Code / Cursor.

3. Внести правку в DSL (вручную или через агент).

4. Настроить CI в GitLab: prepare → fitness_check → publish.

5. Запустить интеграцию через Gitlab CI/CD пайплайн с BeeAtlas (описание есть в документации) или просто «закинуть» архитектуру на портал.

6. Прочитать код ошибки (TECH.01, CPB.03…), исправить DSL, повторить push.

Cypher учить не нужно — только если вы добавляете корпоративные паттерны.

---

7. Ограничения

• Подход не заменяет архитектора и не отменяет экспертную оценку trade-off между качествами системы.

• Мусор на входе — мусор на выходе: проверки валидируют модель, а не прод, если модель не актуализируется.

• Не каждый аспект качества формализуется графом (например, организационные границы по Conway’s law).

• Локальный стенд: Grafana и внешние интеграции — заглушки.

• Cypher/GDS требуют дисциплины метамодели графа.

---

8. Заключение

Агентная разработка усиливает потребность в архитектурном справочнике и автоматических проверках. Чем быстрее генерируются модели, тем важнее единый source of truth и детерминированный фильтр между гипотезой LLM и merge в main.

Связка каталог архитектуры (BeeAtlas) + проверка связей (граф в Neo4j) + правила в CI (фитнес-функции) даёт масштабируемый контроль для архитектора и разработчика. Open-source репозиторий позволяет поднять пилот за день и нарастить правила постепенно — от одного продукта и пяти–десяти фитнес-функций.

Что делать прямо сейчас:

1. Скачайте репозиторий и поднимите стенд за 15 минут — docker compose -f docker-compose-run.yml up -d

2. Опишите первый продукт в Structurizr DSL — шаблон уже есть в beeatlas-doc/templates/workspace.dsl

3. Подключите CI — pipeline-шаблон готов, просто скопируйте из документации

4. Заведите issue или PR на GitHub — проект open-source, мы ждём обратную связь

Начните с pipeline: пусть каждый commit в workspace.dsl проходит автопроверку. Агенты станут продуктивнее не потому, что им доверяют на слово, а потому, что появился короткий feedback loop — как у unit-тестов.

---

Благодарности

Методы графового анализа (раздел 4.2) разработаны в ВКР Почечуры Артемия Андреевича «Метод анализа архитектуры программного обеспечения на поиск уязвимостей» (МАИ, 01.04.02 «Прикладная математика и информатика», 2026).

Работа выполнена под научным руководством Булакиной Марии Борисовны; автор настоящей статьи (Дзюба Дмитрий Владимирович) выступал научным консультантом при разработке методов графовой верификации и их интеграции в BeeAtlas.

---

Полезные ссылки

• BeeAtlas FDM Infrastructure — https://github.com/tech-beeline/beeatlas-fdm-infrastructure

• Документация ПТР и BeeAtlas — beeatlas-doc (метамодель, фитнес-функции, ADR, шаблоны)

• Structurizr DSL — https://docs.structurizr.com/dsl/tutorial

• Модель C4 — https://c4model.com/

• Neo4j Graph Data Science — https://neo4j.com/docs/graph-data-science/current/