AI в проектировании архитектуры: LLM для C4-диаграмм, ADR и trade-off анализа

AI в архитектуре — это не про «нейросеть спроектирует систему за вас». И не про то, что архитектор теперь не нужен. Это про то, что LLM становится вашим спарринг-партнёром — коллегой, который за пять минут накидает три варианта диаграммы, не забудет проверить синтаксис и не обидится на фразу «переделай всё».

Зачем архитектору LLM: не замена, а усилитель

Когда проектируешь систему, рутина съедает до 60% времени. Нарисовать контекстную диаграмму C4 в Mermaid, описать контейнеры, проверить границы bounded contexts, оформить ADR — это механическая работа. LLM способна взять её на себя прямо сейчас. И, что немаловажно, делает она это не хуже мидла-аналитика, потратившего на задачу полдня.

Три основные роли LLM в архитектурной работе:

Генератор диаграмм — создаёт C4, sequence, state-диаграммы по текстовому описанию
Аналитик trade-off — сравнивает варианты решений, подсвечивает риски и неочевидные последствия
Помощник в документировании — оформляет ADR, description к компонентам, диаграммы контекстов по шаблону

Важный момент: LLM не принимает решений. Решение всегда за архитектором. Но качество этих решений растёт, когда у вас есть структурированный разбор альтернатив, а не «ну мы так привыкли».

Генерация C4-диаграмм с помощью LLM

C4-модель (Context, Containers, Components, Code) — пожалуй, самый понятный способ визуализировать архитектуру для не-архитектора. Четыре уровня детализации: от системы в окружении внешних акторов до внутренних компонентов отдельного сервиса.

Рисовать C4 в Mermaid вручную — удовольствие на любителя. Нужно помнить синтаксис, расставлять связи, следить чтобы стрелки не перекрещивались в кашу. LLM решает это элегантно.

Пример промпта для контекстной диаграммы:

1
Ты — системный архитектор. Сгенерируй контекстную диаграмму C4
2
для системы интернет-банкинга в формате Mermaid.
3
Используй C4Context-макросы (flowchart LR).
4
Внешние системы: веб-клиент, мобильное приложение,
5
платёжный шлюз, скоринг-сервис, система банка-партнёра.
6
Ядро — Internet Banking System.
7
Подписи на русском.

На выходе — валидный Mermaid-код, готовый к вставке в проект. На первый взгляд кажется простым, но попробуйте написать такой же код с нуля без единой синтаксической ошибки в diagram-as-code.

C4 (Context, Containers, Components, Code) — иерархическая модель визуализации архитектуры ПО, предложенная Саймоном Брауном. В отличие от UML, C4 заточена под быструю коммуникацию с разными аудиториями: от бизнеса (уровень Context) до разработчиков (Code).

Валидация и доработка диаграмм: цикл архитектор-LLM

Типичный workflow работы с LLM-ассистентом в проектировании выглядит как итеративный цикл. Вы даёте описание системы, LLM генерирует диаграмму, вы смотрите — и либо принимаете, либо уточняете промпт.

graph TD
  A["Архитектор: идея решения"] --> B["Формулировка запроса к LLM"]
  B --> C["LLM: генерация C4-диаграммы"]
  C --> D["LLM: валидация Mermaid-синтаксиса"]
  D --> E{"Синтаксис валиден?"}
  E -- "Да" --> F["Визуализация диаграммы"]
  E -- "Нет" --> G["LLM: автоисправление ошибок"]
  G --> D
  F --> H["Архитектор: ревью диаграммы"]
  H --> I{"Диаграмма отражает задумку?"}
  I -- "Нет" --> J["Архитектор: уточняющий промпт"]
  J --> C
  I -- "Да" --> K["LLM: анализ trade-off решения"]
  K --> L["Генерация ADR-документа"]
  L --> M["Архитектор: финальный ревью ADR"]
  M --> N["Публикация в репозиторий ADR"]

  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style G fill:#7b68ee,stroke:#5a4db2,color:#fff
  style K fill:#7b68ee,stroke:#5a4db2,color:#fff
  style L fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#50c878,stroke:#3a9a5c,color:#fff
  style N fill:#50c878,stroke:#3a9a5c,color:#fff
  style H fill:#f0a500,stroke:#c88400,color:#fff
  style J fill:#f0a500,stroke:#c88400,color:#fff
  style M fill:#f0a500,stroke:#c88400,color:#fff
  style E fill:#e0e0e0,stroke:#999,color:#000
  style I fill:#e0e0e0,stroke:#999,color:#000

На диаграмме — полный pipeline совместной работы архитектора и LLM. Синие узлы — действия архитектора, фиолетовые — LLM, жёлтые — ревью, зелёные — утверждённые артефакты. Архитектор формулирует идею, LLM генерирует и валидирует C4-диаграмму (автоисправляя синтаксические ошибки при их появлении). После ревью архитектор либо принимает результат, либо уточняет промпт — и цикл повторяется. Когда диаграмма одобрена, LLM переходит к анализу trade-off и генерации ADR. Финальный ревью ADR — снова за архитектором.

Примечательно, что цикл универсален: он работает и для sequence-диаграмм, и для state-машин, и для ER-диаграмм. Меняется только промпт — суть та же.

Практический пример: sequence-диаграмма оплаты

Допустим, нужно описать процесс оплаты заказа в e-commerce. Вместо того чтобы полчаса расставлять стрелки, пишем промпт:

1
Сгенерируй sequence-диаграмму Mermaid для сценария
2
«Оплата заказа через платёжный шлюз».
3

4
Участники:
5
- Client (веб-клиент)
6
- OrderService
7
- PaymentGateway (внешний)
8
- NotificationService
9

10
Шаги:
11
1. Client вызывает POST /orders/{id}/pay
12
2. OrderService создаёт платёж и возвращает 202 Accepted
13
3. OrderService асинхронно обращается к PaymentGateway
14
4. PaymentGateway возвращает результат
15
5. При успехе OrderService меняет статус заказа на PAID
16
6. OrderService отправляет событие в NotificationService

LLM генерирует валидный код. Вы вставляете, запускаете — работает. За пять минут получили то, на что ушло бы полчаса (и то если синтаксис Mermaid не подвёл).

Анализ архитектурных trade-off с LLM

Одно из самых полезных применений LLM — разбор компромиссов между архитектурными подходами. Допустим, вы стоите перед классическим выбором: монолит или микросервисы? Сами по себе списки «за» и «против» вы, скорее всего, знаете. Но LLM выдаёт комбинацию факторов, специфичных для вашего проекта — оценивает влияние на time-to-market, стоимость поддержки в первые полгода, требования к команде.

Промпт для trade-off-анализа:

1
Проанализируй trade-off между монолитом и микросервисами
2
для проекта:
3
- Стартап, команда 5 разработчиков
4
- Продукт — SaaS для автоматизации складов
5
- Нагрузка: 500 RPS через год
6
- Бюджет на devops: минимальный
7
- Требования: высокая доступность, быстрый time-to-market
8

9
Выведи таблицу сравнения по критериям и итоговый вывод.

LLM вернёт таблицу с колонками: стоимость разработки, скорость внедрения фич, сложность деплоя, надёжность, стоимость инфраструктуры. Итоговый вывод часто оказывается неожиданным — например, модульный монолит на старте с планом миграции на микросервисы при достижении порога по нагрузке. Это не серебряная пуля, но как минимум структурированная рамка для принятия решения.

Автоматизация ADR через LLM

ADR (Architecture Decision Record) — краткий документ, фиксирующий архитектурное решение, контекст, альтернативы и последствия. Подробно о том, зачем и как вести ADR, — в отдельном посте. Здесь сфокусируемся на том, как LLM ускоряет их создание.

Стандартный шаблон ADR включает:

Заголовок — коротко: что решили
Статус — предложено / принято / отклонено / заменено
Контекст — почему вообще встал этот вопрос
Решение — что выбрали и обоснование
Альтернативы — что рассматривали и почему отклонили
Последствия — что станет проще, а что — сложнее

Промпт для генерации ADR:

1
Составь ADR в формате Markdown по шаблону:
2
Заголовок, Статус, Контекст, Решение, Альтернативы, Последствия.
3

4
Ситуация: выбираем между синхронным REST и асинхронной шиной
5
событий для интеграции сервиса заказов и сервиса уведомлений.
6
Объём: 10 тыс. событий/день.
7
Решение: Kafka + паттерн transactional outbox
8
для гарантированной доставки.

На выходе — готовый документ. Архитектору остаётся вычитать, поправить пару формулировок и сохранить в репозиторий. С 20 минут ручной работы до 5 минут с LLM — когда ADR накапливаются десятками, разница становится колоссальной.

Таблица: ручное создание ADR vs ADR с LLM

Этап	Вручную	С LLM
Описание контекста	5–10 мин	30 сек (промпт)
Формулировка решения	5–7 мин	1 мин (генерация + правка)
Перечисление альтернатив	5–10 мин	1–2 мин (проверка полноты)
Описание последствий	5 мин	30 сек
Итого на 1 ADR	~25 мин	~5 мин

Проверка bounded contexts через LLM

Ещё один практический сценарий: вы набросали границы bounded contexts для домена, но сомневаетесь — не смешали ли разные модели в одном контексте, не пропустили ли агрегаты. LLM выступает ревьюером: вы описываете домен и свои контексты, она подсвечивает потенциальные проблемы.

Промпт для проверки:

1
Проанализируй разбиение на bounded contexts для домена
2
«Управление заказами в интернет-магазине».
3

4
Контексты:
5
1. Каталог товаров — номенклатура, цены, остатки
6
2. Корзина — временное хранение выбранных товаров
7
3. Заказы — оформление, статусы, история
8
4. Доставка — логистика, трекинг
9

10
Вопросы:
11
- Есть ли пересечения ответственности?
12
- Есть ли неявные зависимости между контекстами?
13
- Предложи пересмотр границ, если нужно.

LLM может указать, что «Корзина» и «Заказы» оперируют одной моделью товара, но с разной степенью детализации — это нормально для DDD, но требует явного mapping-слоя. Или что «Доставка» слишком тесно завязана на «Заказы» и стоит рассмотреть порты-адаптеры для слабой связанности.

Стоит отметить: LLM не заменит опытного DDD-практика, но как первичный фильтр грубых ошибок работает отлично. Особенно когда архитектор — единственный на проекте и ему не с кем посоветоваться (привет, стартапы из трёх человек).

Когда LLM не поможет: ограничения

Честно обозначим границы применимости. LLM слаба в трёх вещах:

Понимание бизнес-контекста. Нейросеть не сидит на встречах с заказчиком, не читает его мысли и не знает, что «руководитель отдела логистики ненавидит микросервисы после прошлого провала». Контекст — это то, что вы приносите в промпт сами.
Ответственность за решение. LLM может предложить три варианта архитектуры. Ответственность за выбор и последствия — на вас. Подпись под ADR не поставит.
Специфичные доменные знания. Если ваш домен — редкий и глубокий (скажем, телеметрия космических аппаратов), LLM может галлюцинировать правдоподобно, но ошибочно. Проверяйте.

Ключевое правило: доверяй, но проверяй. LLM — усилитель, а не автопилот.

Заключение

LLM в проектировании архитектуры забирает рутину и оставляет вам суть: придумывать, принимать решения, обсуждать trade-off с командой и заказчиком. Генерация диаграмм, форматирование ADR, первичная проверка контекстов — это механика, и LLM делает её быстро.

Навык, который стоит развивать уже сейчас, — не просто «писать промпты», а выстраивать итеративный цикл «архитектор → LLM → ревью → правка», где нейросеть работает как младший коллега, а вы — как принимающий решения. Пять минут на промпт экономят полчаса рутины. За год набегает внушительно.

И да. Если после прочтения вы подумали: «окей, скормлю ChatGPT описание нашей системы и посмотрю, что выйдет», — вы на правильном пути. Результат не всегда будет идеальным с первого раза. Но итерация — это нормально. Мы потом перепишем.