Suppose you have a client that interfaces with a server which in turn invokes an external service to fulfill some of the client's requests. I'm designing the client and server and need to accommodate the limitations of the external service. I have these options:
- Encapsulate (as much as possible) all code dealing with the service's limitations inside the server application.
- Encapsulate (as much as possible) all code dealing with the service's limitations inside the client application.
- Design both the client and server applications around the external service's limitations.
I had chosen option #1 because the server application was 'closer' to the external service and I didn't want to have to redesign the client if and when the external service was improved. However, now I'm being asked to choose option #3 by the server-side team so we can deal with the external service limitations in the API instead of by handling exceptions. Is there a design pattern I can reference to convince them (or myself) that one option is preferred? (Separation of concerns looks promising, but I haven't convinced myself that it's sufficient because it could also argue for option #2)