I am working on a solution that interacts with several external API's. The basic structure of the code looks something similar to:
- Some basic types that encapsulates the parameters needed to interact with the APIs (for example, resource names, status, ids...). Those types are infrastructure agnostic, so they are only defined in terms of primitive types and without any methods.
- API connectors, which are responsible of transforming the previous types into valid arguments.
- And last, a class that acts as a manager, who reads the serialized types, performs some logic over them and delegates the corresponding actions to the connectors (create resource if not exists or update it).
The key point that I am trying to deal with appears when in some specific cases, the API connectors needs to upload an image. To perform the upload we need to send it as bytes, but in our types we are modeling that images with urls (which could be an S3 route, local one, etc).
-
If we change the core types to include the bytes of the image, we will be carring the entire image for every step of the process, no matter if we need it or not.
-
On the other hand, if we delegate the operation of reading the image to bytes to the connectors, we will we introducing pieces of infrastructure in the connector and we dont see it as a good practice due to the coupling (we need to keep the connectors as much decoupled as possible).
-
And last, if we include the path to bytes operation in the manager, it gets much complicated as it seems because is the connector who answers the question 'do we need to upload the image?'.
I am wondering if there is some software pattern I am missing to solve that or maybe is not possible to keep the manager simple when considering that situation.
Aucun commentaire:
Enregistrer un commentaire