AI для миграции архитектуры: как LLM помогает спланировать переход с монолита на микросервисы

Если вы работали с системами, которым больше трёх лет, то фраза «давайте распиливать» — почти ритуал. Её произносят на планёрках с завидной регулярностью. Ирония в том, что все согласны: монолит пора делить. Но никто не может ответить на главный вопрос — с чего начать и как не развалить прод по дороге.

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

Почему планирование миграции — главная боль

Сам переход с монолита на микросервисы — процесс, который пугает не сложностью кода, а объёмом неизвестности. Вот типичная картина: есть монолит из 300+ модулей, полмиллиона строк кода, часть из которых не трогали со времён, когда jQuery был вершиной фронтенда. Архитектор (или техлид, которому «повезло») должен ответить на вопросы:

Какие модули можно выносить первыми?
Где проходят реальные границы доменов, а не те, что нарисованы в папках три года назад?
Какие зависимости разорвать проще, а какие потянут за собой лавину регрессий?
В каком порядке выносить, чтобы каждый шаг был безопасным и обратимым?

Человек делает это медленно. Две-три недели на анализ кодовой базы, интервью с командами, построение диаграмм. И даже после этого остаётся риск упустить неочевидную связность — модуль billing внезапно вызывает user-profile напрямую, потому что «мы потом перепишем».

LLM закрывает ровно эту щель: берёт на себя механический анализ, оставляя человеку принятие решений.

Как LLM помогает выделить ограниченные контексты

Domain-Driven Design учит нас: границы микросервисов должны совпадать с границами ограниченных контекстов. Проблема в том, что в монолите эти границы размыты годами. Код писали разные люди, с разным пониманием домена, под давлением сроков.

LLM может проанализировать структуру пакетов, сигнатуры методов и имена классов и предложить первичную карту контекстов. Не идеальную — но отправную точку, на которую архитектор наложит свою экспертизу.

Вот практический промпт для такого анализа:

Проанализируй структуру пакетов монолита и выдели ограниченные контексты (Bounded Contexts) по DDD. Для каждого контекста укажи: ядро (core), точки соприкосновения с другими контекстами и зависимости. Критерии: разная бизнес-логика = разный контекст. Общие сущности — повод объединить в один контекст.

Структура пакетов:
1
com.company.order — заказы, корзина, статусы
2
com.company.payment — платежи, возвраты, биллинг
3
com.company.catalog — товары, категории, цены
4
com.company.user — профили, авторизация, роли
5
com.company.notification — email, sms, push
6
com.company.warehouse — остатки, резервирование, логистика

LLM выдаст что-то вроде:

Контекст 1: Торговый каталог (Catalog) — catalog Контекст 2: Управление заказами (Order Management) — order (зависит от Catalog для проверки наличия, от Payment для оплаты) Контекст 3: Платежи (Payment) — payment Контекст 4: Пользователи (Identity & Access) — user Контекст 5: Нотификации (Notification) — notification (зависит от Order, Payment, User) Контекст 6: Склад (Warehouse) — warehouse (зависит от Catalog для товаров, от Order для резервирования)

Важно: это не финальное решение. Это быстрая итерация гипотез, которую архитектор проверяет на реальном коде.

Матрица связности: где рвать, а где не трогать

Одна из самых полезных вещей, которую LLM делает за минуты — строит матрицу связности модулей. Вы скармливаете модели список импортов/зависимостей (хоть в виде текстовой выгрузки grep import), и она возвращает анализ:

Модуль	Зависит от	Сила связи	Комментарий
`order`	`catalog`	Сильная	Заказ проверяет наличие товара
`order`	`payment`	Сильная	Каждый заказ связан с транзакцией
`order`	`user`	Слабая	Только ID пользователя
`notification`	`order`	Средняя	Отправка статусов заказа

На основе такой матрицы LLM может предложить три стратегии первого шага:

Самый независимый модуль — notification. Слабо связан с остальными, его вынос минимально рискован. Хорошо для обкатки процесса миграции.
Максимальный бизнес-эффект — catalog. Если каталог меняется чаще всего и тормозит релизы, его вынос даст быстрый выигрыш.
Ядро системы — order. Самый рискованный вариант, но и самый ценный. Начинать с него можно, только если команда готова к параллельному запуску и откату.

Каждый вариант LLM может сопроводить оценкой: плюсы, минусы, критический путь, необходимые переходные паттерны.

Паттерн Strangler Fig: LLM как планировщик этапов

Стратегия Strangler Fig («удушающая фига») — это когда вы не переписываете монолит, а постепенно «перехватываете» его функции новыми сервисами. Старый код живёт, пока его не заменит новый. LLM помогает составить детальный план: что перехватить на шаге 1, что на шаге 2, где понадобится «игла» — маршрутизатор, направляющий часть запросов на новый сервис.

Пример промпта для планирования по Strangler Fig:

Мы переносим модуль «Каталог товаров» из монолита в отдельный микросервис. Монолит написан на Java/Spring, новый сервис будет на Kotlin/Spring Boot. Опиши поэтапный план по стратегии Strangler Fig:

Какие эндпоинты перехватывать первыми?

Где нужен feature-флаг или роутер (nginx/envoy)?

Как обеспечить согласованность данных с монолитом на переходный период?

Какие тесты написать до начала миграции?

Критерии готовности к финальному отключению модуля в монолите.

Модель выдаст конкретный перечень шагов, который можно обсуждать на архитектурном комитете. Не как истину, а как отправную точку — проработанную, а не просто «надо выделить каталог».

flowchart TD
  Monolith["Монолитная<br/>кодовая база<br/>(500K+ строк)"]
  LLM["LLM-анализ<br/>зависимостей<br/>и вызовов"]
  Contexts["Выделение<br/>ограниченных<br/>контекстов<br/>(Bounded Contexts)"]
  Coupling["Матрица<br/>связности<br/>модулей"]
  Map["Карта приоритетов<br/>для выноса"]
  Plan["Поэтапный план<br/>миграции"]
  Strangler["Стратегия<br/>Strangler Fig"]
  FirstService["Первый<br/>микросервис"]
  Risk["Оценка рисков<br/>и метрики"]
  Monitoring["Мониторинг<br/>и откат"]
  
  Monolith --> LLM
  LLM --> Contexts
  LLM --> Coupling
  Contexts --> Map
  Coupling --> Map
  Map --> Plan
  Plan --> Strangler
  Plan --> FirstService
  Strangler --> Risk
  FirstService --> Risk
  Risk --> Monitoring
  
  style Monolith fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style LLM fill:#7b68ee,stroke:#5a4ab2,color:#fff
  style Contexts fill:#50c878,stroke:#3a9a5c,color:#fff
  style Coupling fill:#50c878,stroke:#3a9a5c,color:#fff
  style Map fill:#f0a500,stroke:#c88400,color:#fff
  style Plan fill:#f0a500,stroke:#c88400,color:#fff
  style Strangler fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style FirstService fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Risk fill:#e0e0e0,stroke:#999,color:#333
  style Monitoring fill:#e0e0e0,stroke:#999,color:#333

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

Оценка рисков: что LLM видит, а человек пропускает

Ещё один сильный кейс — проверка плана миграции на риски. LLM не устаёт и не поддаётся wishful thinking. Если вы дадите ей описание архитектуры и предложенный план, она способна найти:

Скрытые зависимости — модуль A не импортирует B напрямую, но дёргает его через общую таблицу в БД.
Нарушения согласованности — вынос модуля, который пишет в базу, пока монолит продолжает читать из неё же; нужен слой синхронизации или разделение схемы.
Узкие места переходного периода — shared-библиотеки, которые тянут за собой половину монолита.
Неочевидные допущения — «мы думали, что ID пользователя не изменится при переносе, а оказалось, что монолит генерирует их автоинкрементом».

Это не серебряная пуля. Модель может ошибаться, и её выводы нужно проверять. Но она делает то, на что у человека уходят часы скучного аудита кода.

Практический промпт для оценки рисков:

Мы спланировали миграцию модуля «Каталог» из монолита в отдельный микросервис. Описание монолита:

Java 11, Spring Boot 2.x, PostgreSQL (общая база)

Модуль catalog содержит: сущности Product, Category, Price, логику поиска и фильтрации

Модуль order вызывает catalog для проверки цены и наличия

Модуль warehouse вызывает catalog для резервирования

Наш план: вынести catalog в отдельный сервис с собственной БД, синхронизировать данные через CDC (Change Data Capture), на переходный период использовать API-шлюз для роутинга.

Найди риски в этом плане. Что может пойти не так? Какие сценарии мы упустили?

Где LLM бесполезна (и это важно сказать)

При всей пользе LLM в планировании миграции есть зоны, где она не работает:

Понимание бизнес-контекста. Модель видит код, но не знает, что order_priority = 99 означает «VIP-клиент, доставить за час». Это знает только команда.
Политические границы. В реальном мире на миграцию влияет то, какая команда за какой модуль отвечает. LLM не знает, что модуль billing нельзя трогать, потому что команда биллинга в другом часовом поясе и у них свой бэклог на полгода.
Культурные и процессные факторы. Готовы ли команды к владению сервисами? Есть ли практики CI/CD под микросервисы? Настроен ли мониторинг? Это вопросы к организации, не к коду.

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

Практический workflow: как встроить LLM в процесс миграции

Вот пошаговая схема, которую я наблюдал на нескольких проектах:

Сбор артефактов. Выгружаете структуру пакетов, список импортов, схему БД, историю коммитов по модулям (частота изменений — ключевая метрика).
Контекстный анализ через LLM. Промпт из раздела выше — получаете первичную карту ограниченных контекстов.
Матрица связности. Та же LLM по списку импортов строит матрицу «модуль → модуль».
Приоритизация. LLM предлагает 2–3 стратегии первого шага с обоснованием.
План миграции. По выбранной стратегии LLM генерирует поэтапный план по Strangler Fig.
Оценка рисков. Скармливаете модели план — она ищет слепые зоны и противоречия.
Архитектурный комитет. Архитектор и команды обсуждают выводы модели, корректируют план с учётом бизнес-контекста и ограничений.

На шаге 7 LLM уже не участвует — дальше работают люди.

Заключение

LLM не мигрирует ваш монолит. Она не напишет за вас микросервисы и не договорится с командой биллинга о сроках. Но она способна за часы сделать то, на что у архитектора уходят недели: просеять тонны кода, найти зависимости, предложить границы контекстов и подсветить риски.

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

PS. Если после всех расчётов LLM предложит начать миграцию с модуля, который никто не трогал с 2018 года — возможно, модель нашла самый безопасный путь. А возможно, вы скормили ей не тот список импортов. Перепроверьте.