Legacy и миграции

5 мин чтения

Anti-Corruption Layer: как подключить legacy или внешний сервис, не впустив его модель внутрь

Интеграция с чужой системой почти всегда приносит не только API, но и чужие термины, ограничения и исторические решения. Anti-Corruption Layer нужен, чтобы эта чужая модель не стала внутренней моделью вашего продукта.

Legacy-система может называть клиента «контрагентом», хранить статус заказа в числовом коде и требовать странную последовательность вызовов. Внешний SaaS может иметь свою модель аккаунтов, ролей и платежей.

Самый быстрый путь — протащить всё это напрямую в новый код. Через год половина продукта уже знает, что статус 17 означает «активен», а замена внешней системы становится проектом на месяцы.

Какую проблему мы решаем

Anti-Corruption Layer — это слой перевода между двумя моделями.

Снаружи он понимает чужой API, названия, ошибки и ограничения. Внутри он отдаёт системе понятные ей термины и контракты.

По сути, это архитектурный «переводчик». Он не делает внешний сервис лучше, но ограничивает место, где его особенности известны вашему коду.

Что получает бизнес

Главная выгода — снижение зависимости от конкретной внешней или старой системы.

Если поставщик меняет контракт, legacy постепенно заменяется или компания решает перейти на другой сервис, изменения концентрируются в одном месте. Это уменьшает стоимость миграции и риск каскадной переделки продукта.

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

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

Что получает команда

Команда получает чёткую границу: только адаптер знает странности внешней системы.

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

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

Что получает клиент

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

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

Чем мы за это платим

Появляется дополнительный слой преобразований, маппинга ошибок и данных.

Иногда приходится хранить соответствия идентификаторов и состояний между системами. Это может быть сложнее самого API.

Есть риск создать огромный «универсальный адаптер», который сам превратится в новый legacy. Слой должен защищать конкретную границу, а не становиться вторым центром бизнес-логики.

Когда Anti-Corruption Layer не нужен

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

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

Что стоит спросить перед решением

В итоге

Anti-Corruption Layer полезен не потому, что внешние системы «плохие». Просто у них другая история, модель и ответственность.

Хорошая интеграция связывает системы, но не заставляет одну из них жить по правилам другой.