В чем разница между понятиями Anti-Corruption Layer и паттерном Adapter?

Question

[NameOf Var]

Привет.
Пытаюсь в голове уложить по полочкам понятия Anti-Corruption Layer. Чисто формально - не вижу никакой разницы с понятием паттерна Adapter (или Facade). Единственное отличие, которое я на данный момент вижу, это разница в определениях, что Anti Corruption Layer это некий wrapper, который позволяет изолировать ваш домен от влияния чужого домена, в то время как Adapter это тот же wrapper, но который служит для целей интеграции несовместимых частей кода/системы. Взял отсюдда: https://softwareengineering.stackexchange.com/ques...
В другом примере вообще Anti Corruption Layer заменяют понятием Adapter: https://medium.com/solutions-architecture-patterns...

Разберем такой пример. У меня есть библиотека, которая позволяет работать запросами к MongoDB из кода, разработанная официальными разработчиками MongoDB для моего языка программирования. Также у меня есть доменная модель юзера (так и назовем её - User). У юзера есть уникальный идентификатор UserID, который должен совпадать с идентификатором в MongoDB.
В библиотеки для MongoDB для идентификаторов используется тип `primitive.ObjectID`. Т.к. я не хочу в доменной модели ссылаться на типы в базе данных, я создаю отдельный тип `Identifier`, который, по сути, представляет собой обычную строку. Таким образом, в доменной модели UserID будет типом `Identifier`, а сам `primitive.ObjectID` во время маппинга будет конвертироваться в `Identifier` путем обычного преобразования к строке.
Вопрос: в данном случае тип `Identifier` это anti-corruption layer? Есть ли у вас примеры, которые позволяют наиболее точно показать разницу между anti-corruption layer и паттерном adapter?

Answer 1

[gaparchi]

Это паттерны разного уровня, условно anti-corruption layer это уровень архитектуры приложения, а адаптер больше тактический, технический уровень, он не описывает архитектуру приложения, это один из способов реализации.
Т.е. ты можешь реализовать anti-corruption layer с помощью паттерна адаптер, а можешь и с помощью паттерна фасад, или прокси, или еще какого нибудь паттерна семейства wrap-пов, а можешь и наблюдателем.
А может быть у тебя ACL работает в микросервисной архитектуре, и тогда реализация его будет имплементирована паттернами микросервисов, к примеру Сага будет опрашивать ACL или API Gateway возьмет на себя эту функцию.

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

Comments

[NameOf Var]

Понял, спасибо за объяснение.
Если посмотрите на ответ из самого первого комментария в ответе: https://softwareengineering.stackexchange.com/ques..., то там приводят пример с классом Messy. и Reasonable В данном случае класс Reasonable я бы не назвал ни адаптером, ни фасадом, ибо он полностью зеркалит реализацию Messy, но данный класс служит обычным слоем изоляции от зависимости с Messy. Есть ли название у такого типа паттерна?

Answer 2

[Сергей Соловьев]

Anti-Corruption Layer - это понятие из DDD. Оно обозначает слой (это может быть отдельный сервис или функция валидации), который проверяет запрос на корректность.

Адаптер - это больше паттерн проектирования, который, грубо говоря, трансформирует запрос из одного формата в другой. Например, из XML в JSON, или если стоит прокси, то превращает `X-Redirected-From` в `Redirected-From` в HTTP заголовках.

Адаптер может выполнять роль Anti-Corruption Layer и наоборот

Answer 3

[pikada-lab]

Исходя из Синей книги по DDD ACL это вариант интеграции, который состоит из фасадного объекта, адаптера и транслятора. Адаптер не имеет бизнес логики, его задача делать запросы. Фасадный объект - объект в терминах модели интегрируемого контекста без изменений (что бы не создать промежуточную модель между контекстами), транслятор это объект с логикой преобразования одной модели в другую. В итоге получается процесс такой. Служба нашего предохранительного уровня вызывает через адаптер службу другой системы, транслируя запрос в термины другой системы, получает фасадный объект, и с помощью транслятора преобразует его в объект нашей системы, затем возвращает его сервису или возвращает ошибку при трансляции. Обработка конфликтов может быть неизбежна. В подобных случаях рекомендую использовать монаду Either.