I am asked to provide the documentation of a design for a "deal service" that de-couples the user’s requests from the requests to the partners who provide rental rates. the service does so, by looking up a cache, and fetching whatever is missing in a long-running process.
I am thinking about which design pattern would be appropriate for the software. I don't need to write working code, only the design documentation.
I am thinking about the combination of mediator and Flyweight design pattern.
The mediator pattern defines an object which encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Rather than interacting directly with each other, objects ask the Mediator to interact on their behalf, which results in reusability and loose coupling.
On the other hand, The Flyweight Pattern is designed to control object creation where objects in an application have great similarities and are of a similar kind, and provides you with a basic caching mechanism. It allows you to create one object per type (the type here differs by a property of that object), and if you ask for an object with the same property (already created), it will return you the same object instead of creating a new one.
Do you have better suggestions?
Sounds more like Orchestration of the flow. I would simply construct VO and pass it to an orchestrator, then here, I will use command pattern (along with Abstract factory if needed), where each command has responsibility to call partner service(s) and return DealsVO/TO/DTO (whatever the heck that is!). I would also use builder pattern to build your request to each partner service keeping all setters out of the picture making request immutable.