Какой паттерн использовать для задачи получение заказов, отправка статусов заказов из нескольких разных внешних источников?

Question

[Vasyl Fomin]

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

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

В общем , главный вопрос в том, как это все правильно организовать, где указывать с каким сервисом сейчас работаем, создавать ли классы сервисов по одному и тому же интерфейсу или делать какие то адаптеры?

Answer 1

[Макс]

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

Comments

[Vlad Osadchyi]

можно пример реализации фабрики?)

[Макс]

https://designpatternsphp.readthedocs.io/ru/latest...

[Максим Федоров]

Vlad Osadchyi,

class ClientFactory
{
     // тут через контейнер все будет на месте :)
     private $clients;

     public function create(SystemEnum $system): ClientInterface
     {
          // Тут проверки всякого рода
          return $this->clients[$system->getAlias];
     }
}

[Vlad Osadchyi]

Максим Федоров, спасибо

Answer 2

[Максим Федоров]

Начинаем с границ
Очерчиваем границы нашей системы, как-будто у нас есть этот "идеальный заказ".
Это будут интерфейсы некоторых абстрактных реквестов и респонсов.
Реквест на обновление, добавление и респонс на получение и т.д.... И несколько ДТО их реализующие или которые и будут этим интерфейсом сами по себе.

Далее вы строите клиент OrderClientInterface, который выше созданные реквесты отправляет, респонсы возвращает. И на его интерфейс вы завязываетесь. Строите поверх него фабрику, которая построит вам нужный клиент под нужную систему :)

Адаптеры (к слову это и паттерн одноименный)
Клиенты-адаптеры уже будут связывать АПИ внешних систем с интерфейсом вашего абстрактного (имеется в виду интерфейс) клиента. Через guzzle, или через некий свой sdk, уже для вашего домена не важно, дело техники. С авторизацией или без нее... Это детали клиента.

Это довольно общая рекомендация, но стоящая и очень упростит вам работу. Несколько интерфейсов, несколько дто, фабрика и остальное дело техники, просто и надежно

Бизнес-логика
Теперь пишите хэндлеры в вашей бизнес-логикек: из контроллера, демона, команды вызываете нужные хэндлеры и строите запросы. Саму обработку их результата и контроль состояния делаете в сущностях.
Ну я так понимаю, вопрос касался адаптеров.

Answer 3

[vitaly_74]

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