Post #787

Ооо, какая штука! Каталог паттернов работы с легаси-системами: 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 — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией. Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.