⚡️ Переписывать legacy-систему редко значит «переписать код». Обычно самая дорогая часть начинается там, где старый и новый мир должны какое-то время жить одновременно.

Типичная проблема - синхронизация данных между старой БД и новой моделью. На бумаге кажется, что можно взять CDC, подключить Debezium, прокинуть события и жить спокойно. На практике это работает только пока у вас почти прямое соответствие: таблица → событие → таблица.

В реальном legacy всё еще хуже.

Одна запись в старой системе может собираться из нескольких агрегатов в новой. Поля могут иметь другой смысл. Часть данных нормализована, часть размазана по справочникам, часть хранится как «магические» статусы. А ещё при переносе нужно не просто скопировать байты, а применить бизнес-правила: пересчитать состояние, отфильтровать мусор, восстановить инварианты, иногда даже специально повторить старый баг, потому что на нём завязан внешний процесс.

Нормальное решение может выглядеть так:

* события из новой системы публикуются через outbox, а не напрямую из хендлера
* синхронизатор читает сообщения из RabbitMQ или другого брокера
* трансформации делаются явно, через application service или отдельный mapping layer
* операции проектируются идемпотентными, потому что повторная доставка будет всегда
* для каждой внешней записи хранится mapping старого и нового идентификатора
* ошибки не теряются, а уходят в retry/DLQ с понятной диагностикой
* консистентность проверяется отдельными reconciliation jobs, а не верой в «оно доедет»

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

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