Как перевыбор подрядчика влияет на логику приложения

Что проверяют

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

Как отвечать

Сначала уточните, о каком подрядчике речь, и стройте ответ вокруг границы между доменом и интеграцией:

• порт и адаптер: домен знает только интерфейс вроде PaymentGateway со своими моделями и статусами, а DTO и коды ошибок поставщика живут в адаптере. Это слой защиты от чужой модели (anti-corruption layer);
• выбор реализации: в Spring несколько бинов одного интерфейса, выбор через @ConditionalOnProperty или через Map<String, PaymentGateway> по ключу провайдера. Так поставщика переключают фиче-флагом, по доле трафика или по стране;
• различия в семантике: новый поставщик может работать асинхронно через вебхуки там, где старый отвечал сразу. Меняется машина состояний операции, появляются таймауты, повторная доставка колбэков и потребность в идемпотентности;
• данные: внешние идентификаторы и токены старого поставщика обычно не переносятся. Нужна колонка с провайдером у каждой записи и период, когда обе интеграции живут параллельно;
• проверка: контрактные тесты адаптера на WireMock или Pact, таймауты и circuit breaker через Resilience4j, сравнение доли успешных операций до и после.

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

Где спотыкаются

Пропускают DTO поставщика прямо в сервисы и в базу. Тогда смена подрядчика задевает бизнес-логику, миграции и фронтенд.

Считают, что достаточно поменять URL и формат JSON. Главные сюрпризы в другом: статусы, возвраты, частичные списания, лимиты запросов.

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