Ооо, какая штука! Каталог паттернов работы с легаси-системами: https://legacy-modernization.io/

Вытащил из сообщества архитекторов Russian Association of Software Architects

Удушение, миграция, параллельная работа. В связи и импортозамещением (не всё ещё заместили?..) очень актуально.

Как обычно, многие паттерны — это просто здравый смысл, но хорошо, что они названы и собраны в одном месте.

Каталог разбит на 4 части:
— миграция с легаси-системами
— синхронизация данных
— организационные паттерны
+ не паттерны, а перечень типовых проблем и мотивов перехода со старых систем.

Паттерны интеграции:
— "душитель" (по-английски он фикус-душитель, Strangler Fig): откусываем от легаси-системы по одному юскейсу — ставим на входящем потоке роутер, который перенаправляет некоторые частные случаи в новую систему. Сначала единичные, потом всё больше и больше, потом все.

— "пузырь": развитие идеи anti-corruption level — внешние системы и пользователи работают с новой моделью (и функций, и операций), а он преобразует и сохраняет данные в легаси-системах. Постепенно он всё меньше и меньше зависит от легаси-систем, а потом они совсем отключаются — пузырь "лопнул". "Автономный пузырь" — изначально со своим хранилищем данных. "Обратный пузырь" — когда ставим его после легаси-системы, и отправляем в него запросы для обработки, то есть легаси как интерфейс, а в пузыре новая бизнес-логика с новой доменной моделью.

— можно прикрутить к легаси новое API или UI, или отлавливать и публиковать события из неё.

— дальше разные стратегии миграции: пишем в легаси, читаем из новой системы/читаем из легаси, пишем в новую систему. Или делим по сегментам пользователей (по странам, клиентам, юскейсам).

— параллельная эксплуатация. Любимое развлечение, однажды полгода этим занимались.

Паттерны синхронизации данных:

— CDC, чтобы гонять только изменения
— Sync and Backfill — когда у нас два отдельных процесса на синхронизацию новых данных (в реальном времени) и подгрузке исторических (асинхронно)
— Двойная запись (пишем одновременно в старую и новую систему)
— Общая БД

Обратите внимание: миграция требует практически тех же подходов, что и интеграция!

Организационные паттерны:

— AMET (Architecture Modernization Enabling Team) — вот это крутая идея! Временная команда, выделенная на фасилитацию перехода: помогает спроектировать новую архитектуру, не давать угасать импульсу, добавлять экспертизу там, где она нужна. Вот тут подробная статья про AMET https://livebook.manning.com/book/architecture-modernization/chapter-15, из книги Jean-Georges Perrin и Nick Tune 'Architecture Modernization: Socio-technical Alignment of Software, Strategy, and Structure' (на русском вроде её нет)

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

— Inner-Sourced Client Migration: команда со стороны сервиса берется за переписывание кода в клиентских системах (эффективно, но только для тех клиентов, кто готов пустить в свою кодовую базу). Да мы уже сами вам всё перепишем, только перейдите уже на новую версию!

— Dual Track — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией.

Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.