Не складывается все пока в единую структуру
Глаза боятся, руки делают
Во внешнем сервисе есть авторизация, добавление/изменение n-го количества сущностей (пользователь, заказ и т.д.). Основная задача паттерна, обойтись малой кровью при замене одного внешнего сервиса на другой, когда потребуется ее заменить. Или возможность переключаться между несколькими внешними системами.
Допустим вы под таким сервисом понимаете сервис доставки -- такой сервис в будущем понадобится подменить, заменить и т.д... Там есть и работа с пользователями и с заказами.
Простой набросок со Стратегией
Можно придумать некий интерфейс клиента:
// Принимает ваши учетные данные
DeliveryClientInterface::__construct(?string $account = null, ?string $password = null)
// Регистрируем покупателя в сервисе
DeliveryClientInterface::registerCustomer(DeliveryCustomer $customer): int
// Получаем заказы покупателя в сервисе
DeliveryClientInterface::getOrders(int $customerId): DeliveryOrder
// Добавляем заказ покупателю
DeliveryClientInterface::addOrder(int $customerId, DeliveryOrder $order): int
// Оповещение покупателя в сервисе о неком действии, связанной с ним в этом сервисе
DeliveryClientInterface::notifyCustomer(DeliveryEvent $event): bool
И научить свой проект работать с таким кодом, через интерфейсы
// что в конструктор сервиса запихнете, например PochtaClient или PickPointClient,
// с тем и будете работать
class DeliveryService
{
public function __construct(DeliveryClientInterface $deliveryClient, User $user)
}
$userOrders = $this->deliveryService->getOrders($user->getUuid());
Под такой код напишите уже конкретные реализации клиентов, ну например один клиент для Почты РФ, в этих методах у этого клиента реализуйте логику. По сути эти клиенты будут
адаптерами, если под некоторые службы доставки будут уже библиотеки, но вы не захотите под них плясать и нужно будет привести к этому коду.
Далее в клиентском коде подключайте нужный вам клиент через конфиг/контейнер и все будет работать.
