Which pattern to use for obtaining orders, sending order status from several different external sources?

Tell me, what approach pattern structure is better to use for the solution of the following problem:
There is a shop (Laravel), you need to make receiving orders, sending order status from multiple external services and trading platforms for example. Each of the services your authentication method, your formats of the requests/responses, their statuses.

I understand what it takes for each of the external services, to implement separate classes, and maybe each of them need to use the same interface to work with it.

In General , the main question is how to organize where to specify what kind of service are now working to create classes of services via the same interface, or to make any adapters?
April 7th 20 at 15:28
3 answers
April 7th 20 at 15:30
Solution
The interface is created and possibly an abstract class that lists methods common to all services.
Then create a factory which get the class instance of the desired service and call the correct methods.
it can be an example implementation factory?) - delmer_Huels commented on April 7th 20 at 15:33
https://designpatternsphp.readthedocs.io/ru/latest... - Electa.Schumm16 commented on April 7th 20 at 15:36
@Rick27,

class ClientFactory
{
 // here the container everything will be in place :)
 private $clients;

 public function create(SystemEnum $system): ClientInterface
{
 // Here checks of any kind
 return $this->clients[$system->getAlias];
}
}
- Ricardo56 commented on April 7th 20 at 15:39
@vergie.Nicolas, thank you - delmer_Huels commented on April 7th 20 at 15:42
April 7th 20 at 15:32
Solution
Start with the borders
Outline the boundaries of our system, as if we have this "perfect order".
It will be the abstract interfaces of some requests and responses.
Request to update, add, and response to receive etc.... And a few of DTO implement them or which will this interface by themselves.

Next, you build the client OrderClientInterface, which is higher than the created requests, sends, returns response. And its interface you are tied. Build it on top of the factory, which will build you need the right system :)

Adapters (by the way this pattern of the same name)
Clients-adapters will have to link IPAS external systems interface of your abstract (the interface) of the client. Using guzzle, or using a your sdk, already for your domain is not important, a matter of technique. With authorization or without it... It's the details of the client.

It's pretty General advice, but very worthwhile and will simplify your work. Multiple interfaces, multiple, DTO, factory and other business equipment, simply and securely

Business logic
Now write the handlers in your business logical: from a controller, daemon, commands, call the correct handlers and query. The very processing of their result and make in the entity.
Well, as I understand, the question was about adapters.
April 7th 20 at 15:34
now such do. I got the factory exactly one interface for each type of transaction (Deposit refund), any adapters for SASE with your CRM, and decorators (in any time to add functionality without changing old code). and maybe will need a strategy (for decision if the transaction is canceled, what to do).

Find more questions by tags Patterns of designingPHPWeb Development