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

Назовите наблюдаемую проблему

Фраза «монолит устарел» описывает форму, а не ущерб. Более предметные формулировки: выпуск одного модуля регулярно ломает другой; поиск не укладывается в согласованное время; изменение правила требует правок в нескольких местах и часто приводит к расхождению данных.

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

Найдите реальные границы

Прежде чем разделять приложения, разберите ответственность и данные. Кто владеет записью? Кто имеет право менять её состояние? Какие действия должны происходить атомарно? Что будет при недоступности соседнего компонента?

Если несколько сервисов постоянно меняют одни и те же таблицы и не могут быть выпущены независимо, распределение кода по процессам само по себе не создаёт независимую архитектуру. Оно может добавить сетевые сбои к прежней связанности.

Я выполнял переход от монолитной системы к микросервисной ещё до современных ИИ-инструментов. Этот опыт полезен не как аргумент «всем нужны микросервисы», а как понимание цены границ, совместимости, переноса данных и эксплуатации. Иногда лучший следующий шаг находится внутри монолита.

Защитите существующее поведение

Перед изменением зафиксируйте критические сценарии. Часть поведения может быть не документирована, но клиенты на него уже рассчитывают. Разберите исторические исключения с людьми, которые знают продукт, и отделите нужное правило от случайной ошибки.

Проверки должны следовать бизнес-сценариям. Тест, который повторяет структуру нового кода, способен пройти даже при потере старого обязательства. Полезнее проверить права, итог операции, совместимость API и инварианты данных.

Выберите небольшой участок

Хороший кандидат для первой итерации имеет понятную ответственность, наблюдаемую проблему и ограниченное число зависимостей. Опишите, как он будет включён, как сравнить результат и как вернуть предыдущий путь.

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

Не переносите данные вслепую

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

Выбор способа зависит от допустимого простоя, объёма и критичности данных. Зафиксируйте процедуру проверки до переключения. Если откат после миграции невозможен простым возвратом версии, это должно быть известно до начала.

Сравните варианты по цене решения

Рассмотрите хотя бы сохранение текущей структуры с локальными исправлениями, постепенное выделение границ и полную замену. Для каждого назовите ожидаемый эффект, риск, стоимость перехода и момент, когда эффект можно проверить.

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

Когда подключать архитектора

Если команда предлагает полное переписывание, начните с разбора аргументов и альтернатив. Если нужно вести несколько этапов и принимать результат подрядчика, полезно регулярное техническое руководство. Если предстоит реализация своими руками, это уже другая роль и другой объём участия.

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