The Interfaces/Contracts have to be in the Domain layer because that is precisely the last dependency layer.

• Other layers depend on the Domain Layer.
• The Domain Layer is clean, POCO and have no dependencies on any other layer (Persistence Ignorant principle, etc.)

That is a rule/recommendation in Domain-Driven Design (DDD).

You can read about it in many DDD documentation, from Eric Evans and many other DDD folks.

@CESARDELATORRE Thank you for your comments.

What you have written, is certainly true and it makes a perfect sense when you use the repository in the domain layer.

But, this is not a case. The repository interfaces in the solution are used only in the application layer (command handlers).

If the repository interfaces were in the application layer, would it break 'Persistance ignorance' of the domain layer? Certainly no, because the domain layer is not using these repositories at all.

Moreover, 'interface is owned by client' according to Uncle Bob (https://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445). So, in my opinion, having repository interfaces in application layer in this case, would make more sense from perspective of dependencies.

Thinking about it little more, having repositories interfaces in the domain makes sense for me in 2 cases:

1. The domain layer is using these repositories - e.g. in domain services?
2. Because implementation of repositories is in the separate project (as here in *.Infrastructure projects), which depends only on the domain layer we don't want dependency to the application layer.

Here, the point 2 justifies current choice.

Hmm. Have I just answered to myself?

2. “which depends only on”

Yes you just answered it. 😎

Yup. Corrected. Thanks.