External Web APIs models

[SashoKukui]

TL;DR

Where should the models live for an external Web API, or any other external service for that matter?

Longer question:
Our team is using this implementation of Clean Architecture for the last 2 years. We recently started a new project and out of the sudden a question popped up in my head :

Where should the models live for an external Web API, or any other external service for that matter?

It's clear with the DB models - they go to Domain. But what we did previously was to add External Service models into Application. The logic was that they have to be accessible in Infrastructure in order to create interface implementation but we really kept only the DB models in Domain and nothing else.
Recently I've played with a gRPC service and in order to share it's models between projects - they have to live inside the Domain. And from here is my question.
I know it's more of a philosophical one rather than implementation one, but what seems right in this situation - Application or Domain?

Thanks in advance!

[danielbecroft]

Is this consuming an external service, or exposing a separates service?

For consuming a service, I put the models either (a) in Application, or (b) put everything in a separate project. For example:

Application\ExternalService\IExternalService.cs
Application\ExternalService\Models\Customer.cs
Application\ExternalService\Models\CustomerAddress.cs
etc.

then

Infrastructure\ExternalService\ExternalService.cs << implements Application.ExternalService.IExternalService

The Application layer then only uses the interface and models, and can be mocked for testing. The implementation layer in the external service then can use the interface and the models.

[SashoKukui]

All of this is fine, but it does not answer the question.
Let me ask it this way :
What is the problem with Customer.cs and CustomerAddress.cs to be located in Domain project?

Domain\ExternalService\Models\Customer.cs
Domain\ExternalService\Models\CustomerAddress.cs

This way you'll still be able to access those classes from Application and Infrastructure since they both have a reference to Domain.

The question is - is it wrong for those classes to be in Domain and if it is - WHY?

[danielbecroft]

Is there a technical problem with putting them there? No.
Is there a separation of concerns problem? Probably.

The way I understand it, the Domain layer is the business/problem domain. It's the layer that is (read: should) be the only constant when changing external dependencies, storage mechanisms, or APIs consumed. The only reason for the Domain layer to change, should be that the core business domain has changed, or the requirements have changed. E.g. Business needs to store the Customer Postal Address, not just the street address.

An external dependency change shouldn't change the Domain layer. So changing from Google Maps to Bing Maps, as an example, should not touch the Domain project at all.

The Clean Architecture Pattern is just that, a pattern. It's not a hard and fast rule. There are always exceptions to certain situations, and it is flexible. If you feel it's better for the external dependency models to be in the Domain project, rather than the Application, then that's probably okay for your use case.