Eshoponcontainers: [Question] Ordering Queries

[cmeyertons]

In the Ordering microservices, why is the OrderingQueries implementation in the application layer? This seems like it be better suited to be in the Infrastructure layer?

And why can't IOrderingQueries be in the domain layer?

I'm relatively new to DDD and read through the Architecting & Developing ebook, and after looking through the code this seemed odd to me.

I would propose performing the following to avoid confusion:
Move IOrderingQueries to domain layer
Move OrderingQueries to infrastructure layer

I can do the work if approved and necessary

[CESARDELATORRE]

@cmeyertons - Good question. What you say is right for a regular DDD NLayered application.
However, the benefits you get from DDD patterns (many of them restrictions related to Aggregates, etc.) are good for the transactional area of your application. But you don't get much benefits for the queries, or I'd say more, for the queries, if using the same aggregates model, entity classes and Repositories than what you use for the transactions, you get many restrictions that are bad and not flexible for the queries (you could not make certain joins you might want for queries, etc.).

• Queries are made thinking about the Presentation Layer, the client UI.
• DDD-transactions are made thinking about the Domain rules, restrictions and transaction's boundaries.

Those two topics in reality have different "goals" and if you use the same DDD Domain Model for the queries you will get many limitations in those queries..

Queries are idempotent, no matter how many times you query, data won't change.. ;) - Therefore, in most situations it is better to use a simplified CQRS approach (Command and Query Responsibility Segregation).
Therefore, we split the queries logic and code from the transactional area of the application and we apply DDD patterns ONLY for the transactional area.
Even the Domain Model with EF Core is used only by the DDD transactional code, not for the queries.
Basically, only what's triggered by the Commands is applying DDD patterns and using the DDD Domain Model. But not for the queries.

The database in this simplified CQRS approach is the same database (not two databases, one for transactions and one for queries/reads, that would complicate it significantly), but since we're NOT using DDD patterns for the queries (but plain queries using Dapper) and even the model classes used for the queries is different (different Model/DTO classes) you can have a much better flexibility for querying, i.e. certain joins between tables that in the DDD model would be separated in different aggregates.

That's why the Queries are in the application project, because we're applying DDD only to the transactional area. The queries have certain application logic in the SQL queries, so it is more convenient to put it near the application logic. You could move it to the Infrastructure project, but you wouldn't get a lot of value because of that, but you could do it.

See here my detailed explanation (and the coming pages after that):
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/apply-simplified-microservice-cqrs-ddd-patterns

What would be wrong in this case is to put the IOrderingQueries into the domain layer, since the domain layer is only used for the transactional area in our simplified CQRS. Our queries use a different Reads-Model which is more flexible for queries, as you can check out by researching the code.

Bottom-line, "moving the OrderingQueries to the Infrastructure Layer"? could be, but you won't get much value from that and since we're not applying DDD patterns for the Reads-Queries, that was our design reason.

I hope it clarified the question, which is pretty good since the same project is applying DDD. But it is because of the CQRS approach why it is not like that.
Bottom line,

[mvelosop]

Closing this issue. Used to create the (first) post on Simplified CQRS and DDD in the Knowledge Base