Объясните механизм, благодаря которому анти-коррупционный слой защищает доменную модель при интеграции с внешней системой.
Анти-коррупционный слой изолирует доменную модель от чужих терминов, структур и правил, преобразуя внешний контракт в собственную модель системы и обратно. Благодаря этому изменения внешней системы не проникают напрямую в доменный код, но цена защиты — дополнительный код преобразований, тестирование и необходимость явно поддерживать семантические различия.
Подход возник как практическое решение для интеграции с унаследованными системами, сторонними продуктами и соседними доменами, чьи модели нельзя безопасно принять как собственные. В терминах предметно-ориентированного проектирования это один из способов сохранить целостность модели ограниченного контекста.
Без такого слоя команда часто начинает повторно использовать чужие сущности и статусы. В результате внешние ограничения становятся частью внутреннего языка системы, а изменение поставщика или интеграционного контракта требует затрагивать доменные правила.
Предположим, внешняя система считает клиента активным, если у него есть хотя бы один действующий договор, а внутренняя система использует понятие разрешённого покупателя, учитывая ещё кредитный лимит и юридические ограничения. Простое копирование внешнего статуса создаёт ложное ощущение, что эти понятия эквивалентны.
Если внешний объект передаётся внутрь без преобразования, доменный код начинает зависеть от чужих названий полей, жизненного цикла и неоднозначных значений. Последствия — утечка чужой модели, сложные изменения, неявные бизнес-правила и риск неверных решений на границе интеграции.
Анти-коррупционный слой обычно состоит из адаптеров взаимодействия, преобразователей данных и явных правил интерпретации. На входе он принимает внешний контракт, проверяет его допустимость и переводит его в локальные команды или значения; на выходе преобразует локальный результат в формат, который понимает внешняя система.
Ключевой механизм — не механическое копирование полей, а семантическое отображение. Внешний статус может преобразовываться в локальное решение, внешний идентификатор — связываться с локальным идентификатором, а несовпадающие состояния — обрабатываться явным правилом отказа или отдельным локальным состоянием.
Доменная модель должна оперировать собственными понятиями и не знать о формате внешнего API, его DTO или особенностях хранения. Зависимость от внешней системы остаётся, но локализуется на границе; домен зависит от своего контракта, а интеграционный код реализует преобразование между двумя моделями.
Анти-коррупционный слой особенно полезен при различии терминов, жизненных циклов, инвариантов и ответственности. Он не устраняет сетевые ошибки, задержки или рассогласование данных: для них отдельно нужны тайм-ауты, повторные попытки, идемпотентность, наблюдаемость и политика обработки частичных отказов.
Главный компромисс — стоимость явного перевода. Появляются дополнительные типы, мапперы, тесты соответствия и необходимость обновлять правила при изменении обеих систем. Если модели почти совпадают, стабильны и принадлежат одной команде, полноценный анти-коррупционный слой может быть неоправданным усложнением.
Сервис оформления заказов интегрируется с устаревшей системой расчёта налогов. Внешняя система возвращает коды налоговых режимов, использует составной идентификатор организации и может отвечать промежуточным статусом, тогда как домен заказа должен принимать решение: разрешить оформление, отложить его или отклонить.
Рассматривались три варианта. Прямое использование внешних объектов было быстрым, но протекало бы в домен и связало бы его с кодами поставщика. Общая каноническая модель упростила бы обмен между системами, но потребовала бы согласовать единую семантику, которой фактически не существовало. Отдельный анти-коррупционный слой потребовал больше начальной работы, зато оставил налоговые коды и переходные статусы за границей.
Выбрали третий вариант: адаптер интеграции переводит ответы поставщика в локальные решения, сохраняет внешний идентификатор только в интеграционном контуре и явно обрабатывает неизвестные коды. В результате замена формата поставщика не меняет доменные правила; при этом команда отдельно тестирует преобразования и контролирует ошибки, которые нельзя безопасно интерпретировать.
Обычный адаптер может решать техническую задачу совместимости интерфейсов: например, скрывать транспорт или формат вызова. Анти-коррупционный слой решает более широкую задачу — защищает смысл локальной модели, включая переименование понятий, преобразование жизненного цикла и применение правил, когда прямого соответствия между объектами нет.
Поэтому технический адаптер может быть частью анти-коррупционного слоя, но сам по себе ещё не гарантирует защиту домена. Если он лишь копирует внешний объект внутрь, чужая семантика всё равно протекает через границу.
Он должен скрывать внешний контракт и переводить ошибки интеграции в локально понятные результаты, но не обязан притворяться, что внешний вызов является локальной операцией. Тайм-аут, отказ или неопределённый результат должны сохранять свою значимость для бизнес-сценария.
Например, слой может вернуть локальное состояние ожидания проверки, а не замаскировать недоступность как отрицательный ответ. Политики повторов, идемпотентности и компенсации должны быть согласованы с бизнес-процессом, иначе защита модели превратится в источник скрытых ошибок.
Нужно отделять версии внешних преобразователей и проверять их на реальных или зафиксированных примерах контрактов. Пока старый контракт ещё используется, можно поддерживать несколько переводчиков, сохраняя один стабильный локальный контракт для домена.
При этом важно тестировать не только наличие полей, но и семантику: значения статусов, обязательность данных, допустимые переходы и поведение неизвестных вариантов. Такой подход локализует изменения, но не делает их бесплатными: устаревшие версии нужно своевременно выводить из эксплуатации, а правила преобразования — наблюдать и документировать.