Архитектуру нарисовали. А как убедиться, что очередная доработка её не сломала?

В БКС Финтех описали переход от отдельных диаграмм Draw.io к общей модели Structurizr DSL, хранящейся в Git. Авторы работают с ландшафтом из 20+ систем и разделили описание по доменам. Здесь интересен не сам формат диаграмм, а возможность проверять изменения архитектуры теми же средствами, которыми проверяют изменения кода.

Разберём маленький учебный пример: портал документов, единый контентный API и объектное хранилище. Порталу разрешён только API, а прямое обращение к хранилищу запрещено архитектурным решением.

В модели Structurizr это можно выразить так:

workspace "Документы" { model { portal = softwareSystem "Портал" api = softwareSystem "Контентный API" store = softwareSystem "Объектное хранилище" portal -> api "Получить документ" "HTTPS/REST" api -> store "Читать объект" "S3" } views { systemLandscape "landscape" { include * autoLayout lr } } }

Допустим, разработчик предлагает ускорить скачивание и добавляет portal -> store. Получится красивая схема — и нарушение утверждённой границы интеграции. Новый цвет стрелки такое решение не исправит.

Что я бы проверял в pull request с изменением архитектурной модели:

1. Синтаксис и целостность DSL. Команда Structurizr: structurizr validate -workspace workspace.dsl. Она проверяет сам workspace, но не знает внутренних правил конкретной компании. 2. Собственные ограничения: отдельный автоматический тест запрещает прямую связь portal → store, а для внешних интеграций требует указать протокол и владельца контракта. 3. Изменение модели: в diff видно, какие системы и связи добавлены, удалены или переименованы. Если меняется внешний контракт, требуется описание совместимости и план миграции. 4. НФТ: для новой связи должны быть определены таймаут, повторные попытки, авторизация и поведение при недоступности второго сервиса. 5. Архитектурное решение: ссылка на ADR объясняет, почему граница проведена именно здесь.

Как подключить к этому ревью LLM? На вход подаём не одну новую диаграмму, а связанный набор: утверждённую версию архитектурной модели (нужные системы и их связи, с указанием версии), diff предлагаемого изменения, действующие ADR по затронутым системам и относящиеся к ним корпоративные правила интеграции и НФТ. Просим модель проверить каждую изменённую связь на соответствие этим материалам и вернуть конкретные замечания: связь → пункт правила или ADR → обнаруженный конфликт и риск → предлагаемое исправление. Если нужного правила нет в контексте, это вопрос на уточнение, а не повод домыслить ответ.

В нашем примере LLM должна заметить новую связь portal -> store, указать конфликт с ADR о едином контентном API и предложить сохранить маршрут portal -> api -> store либо вынести пересмотр ADR на согласование. Замечания сверяются с исходными документами: Structurizr проверяет корректность DSL, отдельные тесты — формальные архитектурные запреты, а архитектор — обоснованность выводов LLM. Иначе можно получить «проверено», но так и не выяснить, что именно.

Практический критерий зрелости простой: после изменения модели команда получает не только новую картинку, но и машинно проверяемый результат — что не нарушено, что изменилось и на каком основании разрешено. Это полезнее очередного комплекта диаграмм, разошедшихся между собой ещё до согласования.

Пример выше учебный; он показывает метод контроля и не описывает внедрение в конкретной компании.

Источники: БКС Финтех — кейс Architecture as Code и LLM: https://habr.com/ru/companies/bcs\_company/articles/1006944/ Structurizr — документация проверки DSL/workspace: https://docs.structurizr.com/cli/validate

#КорпоративнаяАрхитектура #ArchitectureAsCode #Structurizr #АрхитектурноеРевью #ИИВАрхитектуре