Clean architecture - how to manage use cases that depends on external apis

Question

How to apply clean architecture concepts in a software that depends on External APIs.

Example:

A business that offers some kind of subscription to its users. Its convinient to store some subscription data and how its related with the users inside our database.

The Subscription use case is responsible to receive data from a request, send part of this data to the External Subscription API, validate the response to ensure that the subscription was generated and finally persist a Subscription Entity to a internal database.

I'd put this logic inside the SubscriptionRepository that depends on a "ExternalSubscriptionRepository", is that a fair implementation?

Considering that these payment apis usually have very especific rules and processes, how to prevent our Subscription use case to be very coupled with this logic? Is that a problem or its part of the game?

Ex: External Service A, needs 1,2,3 parameters to create a Subscription and External Service B needs parameters 2,4,1.

Answer 1

Treat it like any other external API.

The adapter lets you hold the API at arms length. Rather then be victimized every time the API changes you can express what you need to the adapter. If how you get what you need changes then the adapter, not your core logic, changes and handles getting what you need in this new way.

The use case interactor can build, store, and use entities based on what it gets from this API. There's a lot of power when done this way. Also a fair bit of work. Understand what that work is getting you before you do this. Express what your needs are. Don't just access everything the API has if you don't need it.