Конспект по теме 'Anti-corruption layer' из категории 'Паттерн | .NET backend study

Конспект по теме "Anti-corruption layer" из категории "Паттерны"

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

Решаемая проблема

Представим, что мы пишем систему, ведущую учет отпусков сотрудников. И наша система взаимодействует с корневой ERP системой(система планирования ресурсов предприятия - Enterprise resource planning) нашей компании. Наша система вызывает ендпоинты ERP системы напрямую, передавая туда данные.

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

В этом случае, если взаимодействие с ERP системой было тесно переплетено с бизнес логикой внутри нашей системы, то нам придется подвергнуть ее сильному рефакторингу. Т.к. нам придется заменять отправку HTTP-запросов на работу с очередями.

Решение

Для решения проблемы необходимо изолировать слой интеграции - называемый Anti-corruption layer (ACL). Данный уровень будет преобразовывать обмен данными между двумя системами, что позволит не зависеть внутреннему устройству приложения от изменений в сторонних системах.

Схематично, взаимодействие выглядит вот таким образом:
Система учета отпусков → ACL → ERP система

Системы ничего не знаю о внутреннем устройстве друг друга (например, о моделях). ACL имеет доступ к обоим системам и их моделям. Также наша бизнес логика ничего не знает о способе взаимодействия со сторонней системой. Нам известно только то, что нужно передать определенный объект в ACL. А каким образом он будет доставлен в ERP систему - нас не интересует. Вся логика взаимодействия с ERP системой (прямой вызов ендпоинта, пуш в RabbitMQ и т.д.) лежит на нашем ACL.

Работа происходит примерно по следующему алгоритму:

1) Система учета отпусков вызывает метод из ACL, передавая туда свою модель;
2) ACL трансформирует модель нашей системы в модель ERP-системы и оправляет данные в ERP систему(синхронно или асинхронно).

В случае синхронного взаимодействия (через HTTP-вызов):

3) ERP система обрабатывает запрос и возвращает результат в ACL в виде своей модели;
4) ACL преобразовывает модель из ERP системы в модель нашей системы по учету отпусков и отдает ее нам.

Недостатки подхода

⦁ Наличие ACL ухудшит производительность взаимодействия двух систем по причине добавления нового слоя по обработке;
⦁ Добавляя ACL увеличивается сложность системы, т.к. этот слой также нужно будет поддерживать.

Преимущества подхода

⦁ Не нужно изменять систему под интеграцию с другой системой. Вся логика по адаптации моделей и способа взаимодействия будет находиться в ACL;
⦁ Обработка ошибок по взаимодействию двух систем может быть вынесена в отдельный слой. Таким образом наше приложение не будет хранить в себе обработку специфических ошибок, делегируя это ACL.


Вернуться в бэклог категории Паттерны