search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.37k stars 9.99k forks source link

In Dmain Driven Design (DDD) , Should be use the IRepository contract in the application layer or in the domain layer? #51511

Closed akbaramd closed 10 months ago

akbaramd commented 1 year ago

I have been involved for a while now in which layer should the repository contract be, the domain or the application?

I know that the repository contract in DDD is defined inside the domain layer, but when the application layer needs a method that is not in the repository, it must tell the domain layer to add it.

And this is against the principle of dependency inversion, in my opinion, because changing the logic at the level of the higher layer should not effect the lower layer.

Because the Domain layer at the lower level does not know what the application layer needs to provide.

(If we do not consider the Generic repository).

And we have the principle that "contracts has owned by the client side" that the existence of a repository in the domain violates this principle because we do not use contracts in the domain layer

martincostello commented 1 year ago

This looks more like a general question about software engineering, rather than anything specific to ASP.NET Core.

Have you considered asking this question over at https://softwareengineering.stackexchange.com/ instead?

akbaramd commented 1 year ago

This looks more like a general question about software engineering, rather than anything specific to ASP.NET Core.

Have you considered asking this question over at https://softwareengineering.stackexchange.com/ instead?

For me, this issue is more relevant at the Net Core level. And I would like to know the opinion of programmers who are in this field

Rzassar commented 1 year ago

I couldn't agree more. I always put the Repository contracts in the application layer. In other words:

Although DDD states that repository interfaces should be declared in the Domain layer, I see no benefit in declaring IRepository there: o As the main consumer of the repositories is the Application layer and the implementation is in the “Infrastructure” layer. Hence, the Domain layer has nothing to do with the repositories. o On the other hand, I think it is far better to define them in the “Application” layer, as they may emit some business logic with it (e.g., consider ICustomerRepository has a GetTopTenCustomers(); method means that the customer repository emits some meaningful business logics, while, the business logic has nothing to do with the “Domain” layer.

BTW, I also think you should ask it in a broader area. This problem is an architectural design matter and should be asked in a more general group that encompasses all the software engineers.

akbaramd commented 1 year ago

I couldn't agree more. I always put the Repository contracts in the application layer. In other words:

Although DDD states that repository interfaces should be declared in the Domain layer, I see no benefit in declaring IRepository there: o As the main consumer of the repositories is the Application layer and the implementation is in the “Infrastructure” layer. Hence, the Domain layer has nothing to do with the repositories. o On the other hand, I think it is far better to define them in the “Application” layer, as they may emit some business logic with it (e.g., consider ICustomerRepository has a GetTopTenCustomers(); method means that the customer repository emits some meaningful business logics, while, the business logic has nothing to do with the “Domain” layer.

BTW, I also think you should ask it in a broader area. This problem is an architectural design matter and should be asked in a more general group that encompasses all the software engineers.

I agree with your opinion; in fact, that was the reason for my question. But isn't this GetTop10Customer domain logic? In DDD, we have to separate the domain logic from the application. But the same example that you mentioned, in my opinion, is domain logic and no application logic is involved in it.

ghost commented 10 months ago

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!