.netdomain-driven-design

Questions about building an architecture using DDD model

I'm studying domain-driven design and building a solution (using C#, .NET 8) with 4 layers: Presentation, Application, Domain and Infrastructure. I have some questions about how to proceed with the implementation:

  1. I saw in some examples the application, domain and infrastructure interfaces all concentrating in domain layer. But, when I building the my projects, I was wondering if is more organize to put an interface in your respective layer. Example: UserApplicationService has IUserApplicationService. Can I put the IUserApplicationService in Application layer or does it have to be in Domain layer?

  2. I'm using Dapper to get the data from SQL Server in Infrastructure layer, through the repositories. I have to get all active users, so, in my UserRepo has: select * from user where active = 1. But, get the active users is a business rule. So I have 2 options: maintain the select with where clause or get all users and filter them in domain layer. If I choose the first option, I not following the principles of DDD? (because the rule of get active users is in infrastructure layer). But if I choose the second option, and if I have 1.000.000 clients, I will lose performance. How to proceed in this case? What is the best solution for this example?

  3. I have a worker service project. He has to be in Presentation Layer because is a Startup project or in Application layer because doesn't have input of users and just manipulating data received by the domain layer services?

Solution
    1. You should place application interfaces on the application layer. They are contracts of your application, not your domain.
    2. Your repository methods are meaningful. For example, GetAllActiveUsers() in your case. So the implementation of that method must return meaningful results. So it's your repository implementation responsibility to return meaningful results and the logic goes there. Note that getting a list of active users to modify them is not recommended. In all your use cases, you should modify only one instance of an aggregate in one transaction. But if it's for querying purposes, it might be okay (maybe it belongs to a domain service rather than a repository).
    3. It can be in the application layer. Some would make the application layer their web API. But you must decide for yourself. Do you have some presentation concerns that would pollute your application layer? I separate these two to comply with separations of concerns. Another thing to consider is reusability. If you separate these, you can reuse your application layer use cases.