Шаблон адаптера в гексагональной / луковой архитектуре SOA

Question

Предполагая, что у вас есть приложение, которое требует 2 услуги, например. Application, Service1, Service2

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

Или вы должны иметь Application напрямую подключиться к обоим Service1 а также Service2?

С другим уровнем косвенности вы можете уменьшить зависимость от Application слой, особенно по отношению к внешним услугам, например. "Paypal", "Facebook", "CyberSource" и создайте адаптеры сервисов приложений, которые больше подходят для вашей парадигмы программирования. В конце концов, это действительно наносит ущерб производительности, когда все разработчики знакомятся со всеми этими различными API. Фасад / адаптер облегчит разработку, защищая приложение от инфраструктурных изменений. например. Компания потерпела неудачу с CyberSource и решила использовать вместо нее Paypal, к счастью, ваше приложение защищено, и вам нужно было только заменить адаптер и ничего больше.

Тем не менее, адаптер определенно создает негибкость. По мере усложнения приложения адаптер также становится негерметичным. Тогда у вас могут возникнуть 3 проблемы: неплотная абстракция, ленивый слой (слой, который делает недостаточно из-за слишком большого количества дырок), и нарушение принципа общего замыкания, так как каждый раз, когда вам нужно изменить пользовательский интерфейс, вы должны изменять не только ваше приложение, но и ваши адаптеры.

И что происходит, когда Service2 это уже внутренний сервис в той же компании? Стоит ли создавать адаптер для каждой подсистемы? Что если ваша команда маленькая? Что делать, если у вас есть десятки команд с разнообразным набором технологий? Есть ли какое-либо руководство для правильности добавления еще одного уровня косвенного обращения вместо простого вызова службы?

Answer 1

Я думаю, что вы должны разработать свое приложение так, чтобы оно зависело от интерфейсов, удобных для вашего приложения, независимо от того, рассматриваете ли вы использование сторонних сервисов. Ваша идея использования адаптера / фасада хорошая, но я не вижу причин для лечения Service1 иначе, чем Service2,

Если мое приложение делает виджеты, я должен просто позвонить MyService.MakeWidget(args); Тот факт, что эта операция координирует поведение или 2 разных внешних сервиса, является деталью реализации.

Я думаю, что фактор удобства более важен, чем цель замены внешних зависимостей (хотя обе они включены OA). Удобные интерфейсы улучшают описание вашего приложения за счет косвенности.