Third Parties

[andrew1555]

Hi

Can application layer reference third parties such as https://github.com/Adyen/adyen-dotnet-api-library. For example if we had a usecase for TakePaymentCommand, this would need to connect to Adyen to take payment.

If we keeping Application free from third parties wouldn't this mean I need to reproduce whole return models from Adyen of which there are lots https://github.com/Adyen/adyen-dotnet-api-library/tree/develop/Adyen/Model.

We also use PayPal and Amazon pay in our applications, so having a single IPaymentInterface wouldn't make sense as we need 3 different implementations at once, and then if we called it IPayPalInterface doesn't this couple us to PayPal anyway?

I might be overcomplicating this, so any ideas would be great.

[mweel1]

I believe this functionality belongs in infrastructure.

As far as instantiating different classes for a given interface. I would develop a factory class that takes some value and returns the correct payment implementation.

[andrew1555]

Thanks, the bit I'm unsure about it putting Adyen specific fields into the application. For example say we need to save AdyenUniqueId into our DB we would need to pass this back into the application use case. But as we don't reference Infra layer anything we pass back has to be declared in the application layer, so then we are creating a model with AdyenUniqueId inside and by doing so it becomes tied to Adyen wording, this DTO wouldn't easily swap to a different payment provider.

[mweel1]

Couldn’t you use PaymentProviderUniqueId and and then persist the type of payment method that it is? If not your application return models could implement a return interface from the payment processors which would have different properties if you couldn’t find a common set of properties between your payment providers. I haven’t tried this, but maybe your command could return the interface giving you multiple DTOs to return?

…

On Nov 30, 2021, at 9:10 AM, andrew1555 ***@***.***> wrote:  Thanks, the bit I'm unsure about it putting Adyen specific fields into the application. For example say we need to save AdyenUniqueId into our DB we would need to pass this back into the application use case. But as we don't reference Infra layer anything we pass back has to be declared in the application layer, so then we are creating a model with AdyenUniqueId inside and by doing so it becomes tied to Adyen wording, this DTO wouldn't easily swap to a different payment provider. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[andrew1555]

Hi

Another interesting problem is the response returned from the API calls. So when we make the API call we are sent back a data structure which we then must pass back to the web and output into a hidden field to be picked up by their JS to show payment options.

Therefore in order to do this we need to duplicate this data structure exactly in the application layer, then map their response to this and pass back up the chain which feels wrong to me, and by replicating the class exactly aren't we coupled to them anyway as swapping out the implementation wouldn't be easy now.

The possible solutions I think are to reference the component directly then we can pass back their object to the web controller, or is it ok to bypass the application layer and talk directly to the infrastructure layer?

I can't come up with a nice solution here which doesn't feel like I'm breaking the rules.

Thanks

[mweel1]

You could return the API return model in your application command handler. The reason mapping still might make sense is your UI will probably not need all the data your api returns. Maybe not though.

…

Sent from my iPhone

On Dec 2, 2021, at 7:31 AM, andrew1555 ***@***.***> wrote:  Hi Another interesting problem is the response returned from the API calls. So when we make the API call we are sent back a data structure which we then must pass back to the web and output into a hidden field to be picked up by their JS to show payment options. Therefore in order to do this we need to duplicate this data structure exactly in the application layer, then map their response to this and pass back up the chain which feels wrong to me, and by replicating the class exactly aren't we coupled to them anyway as swapping out the implementation wouldn't be easy now. The possible solutions I think are to reference the component directly then we can pass back their object to the web controller, or is it ok to bypass the application layer and talk directly to the infrastructure layer? I can't come up with a nice solution here which doesn't feel like I'm breaking the rules. Thanks — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.