В этой статье
Выберите границу с видимым бизнес-результатом
В старой системе заказов изменение отчёта требует полного развёртывания. Отчётность — полезная первая граница, если чтение отделяется от записи заказов. Замена центральной транзакции сразу может затронуть скрытые зависимости. Выбирайте часть по доказательствам, не по несовременности кода.
Шаблон Strangler Fig постепенно заменяет возможности вокруг существующей системы. Здесь маршрутизатор направляет отчёты в новую реализацию, сохраняя заказы. Самому маршрутизатору нужны мониторинг и резервный путь. Постепенность снижает риск, только если каждую часть можно независимо обслуживать и оценивать.
Начните с доказательств сбоев и сложности изменений
Составьте карту инцидентов, сроков выпуска, хрупких модулей, неподдерживаемых зависимостей, ручных обходов и дефектов данных. Одна «старая технология» не обосновывает замену.
Определите неизменное: контракты, рабочие календари, ID, отчёты, интеграции и регуляторные доказательства. Эти ограничения задают миграцию сильнее целевого стека.
Выделяйте границы вокруг ценных изменений
Окружите тестируемой границей часто меняющуюся или рискованную функцию. Стабилизируйте вход и выход до смены внутренностей; не превращайте старую БД в новый публичный API.
Постепенный путь направляет выбранные сценарии в новый компонент, оставляя старую систему главным источником в остальных. Используйте явное владение и совместимость, не невидимую вечную двойную систему.
Заменяйте по одной полезной границе за раз
Миграция должна сохранять проверяемый путь возврата.
Изучите существующую систему
Определите, какое изменение сейчас дорого или ненадёжно.
Создайте точку разделения
Окружите выбранную функцию устойчивым интерфейсом.
Перенесите и сравните
Сверяйте данные и останавливайтесь при нарушении критериев приёмки.
Мигрируйте данные со сверкой и условиями остановки
Определите канонического владельца на каждой фазе, проверьте типичные миграции, сверьте количества и бизнес-итоги, сохраните окно отката. Избегайте двусторонней записи без исполняемой наблюдаемой политики конфликтов.
Каждому шагу нужны измеримый результат и условие остановки. Если не улучшаются безопасность выпуска, восстановление, пользовательский путь или стоимость, не выделяйте компоненты ради вида архитектуры.
Сохраните поведение до его изменения
Зафиксируйте типичные входы и выходы старого пути, включая неудобные исторические случаи. Странное поведение бывает бизнес-правилом или привычно обходимой ошибкой. Обсуждайте различия с владельцем процесса, не считая новый код правильным лишь потому, что он чище.
Для отчётов только на чтение запустите оба пути на одном снимке, сравните суммы, даты и включённые записи. Исследуйте расхождения. Не отправляйте живые записи в обе системы для теневого сравнения без проекта согласованности: это дублирует эффекты. Сначала установите владельца каждой записи и передачу изменений при переходе.
Переносите по одной возможности
Пример миграции отчётности только для чтения. Запись требует отдельного проекта владения и синхронизации.
Зафиксировать базу → реализовать границу → сравнить результаты
Различия понятны и критерии выполнены?
Да
- Направить ограниченный трафик → наблюдать
- Удалить старый путь после согласованной проверки
Нет
- Сохранить существующий маршрут
- Исследовать различия → повторить сравнение
Откат должен учитывать данные после переключения
Вернуть старый интерфейс просто, только если он понимает текущие данные. До перехода решите, совместимы ли записи, можно ли воспроизвести журнал или есть точка, после которой безопаснее исправлять новую систему. Назовите границу открыто, не объявляя любой выпуск обратимым.
После периода наблюдения удалите старый путь, задания, ключи и правила мониторинга, иначе придётся бесконечно обслуживать обе системы. Измеряйте успех по исходной проблеме: изменение отчётности выпускается независимо, результаты согласованы, ответственность ясна. Модернизация части завершена при отключении старой зависимости, не появлении нового экрана.
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Когда оправдано полное переписывание?+
Когда постепенные границы не сохраняют обязательное поведение или старую платформу нельзя эксплуатировать во время перехода. Всё равно нужны доказательства миграции, равенства функций и отката.