Query Handlers and responsabilities

[Lobosque]

Hi, congratulations for the effort putting this up.

I have one question regarding the query handlers. Why are they in Application? Doesn't that mean that you are coupling your Infrastructure with business logic? Just want to understand what weighted your decision and what you would suggest for a more strict decoupling.

[dmoka]

I am not the owner of the repo, but I try to give me point of view on it. In DDD, in the application layer the business use cases are orchestrated. The queries and the corresponding handlers reflects the actual business use cases, therefore the Application layer is a good place for them. Note, that in this layer there is not much business logic happening, and all of them are delegated mostly to the Domain entities which are part of the Domain layer.

I hope it helps, though let's see what the owner's opinion is about it.

[kgrzybek]

Hi @Lobosque I agree totally with @mirind4, thanks for that answer!

What I can add:

• you should treat each use case separately. If you only need to get data from the database (simple query) moving query handling to another layer has no benefits. Some people even handle some writes in the Application Layer (if they are very simple) and in Domain Layer (if they are complex). So you can have "multiple" architectures (clean, 2 layer, 3 layer etc) in one system. It depends on what you need to do to handle a particular use case.

• Domain Model is in separate layer and assembly because it should be isolated from infrastructure (persistence ignorance) for different reasons (DDD tactical patterns, Ubiquitous Language, unit testing etc). Query handling cannot be isolated from persistence and cannot be unit tested. For query handling, you can write integration tests which must be coupled to infrastructure - because this is the purpose of the integration test.

[Lobosque]

@mirind4 @kgrzybek thank you for your replies! I am closing the issue as they answer my initial question/request.