José Luís Vaquero Cuevas2 months ago

I think that CQRS line could be confuse. "Non-domain queries" doesn't exist. Queries should use the domain language to apply filters. Queries should has context along with the business. Not taking into account the domain gives you queries like:

"Give me all the products that were deleted in this year"

instead of :

"Give me all discontinued products of the current campaign"

Luigi Dallavalle José Luís Vaquero Cuevas23 days ago

Interesting comment, do you mean that the read model (the other model which the author refers to) should speak the domain language?

José Luís Vaquero Cuevas Luigi Dallavalle22 days ago

Yes. I think that quering is a business concern too. Query should speak the business ubiquitous language. In other case you can fall into hiden non domain solutions and everything messes up.

I.e. Discontinued products can be seen as some kind of soft delete except discontinued products is considering the domain. You could see soft deletes as a technical solution for the "you can not delete nothing" requisite but this is bad because when you query the read model to -show product catalog- you are putting a "hiden" filter (where delete = false) which no domain user is aware. You have to transform the tech solution into domain solution; that is, products are not deleted, are discotinued. And, when you query, the domain users are aware of the state of the entities and the queries should be aware too. So queries has to be domain aware just to not hiding things.

Another reason is that helps to keep the level of abstracion you should have.

I.e. You create this query: "Give me all the products that were deleted in this year" when you want to list deleted products in the current campaign. But, ¿What happens if the new entering campaign changes and it is 3 years long? You have to create another query: "Give me all the products that were deleted betwen these years". This is ugly. If you have domain queries -"Give me all discontinued products of the current campaign"- the only thing that changes in your system is the thing that realy changes in the domain: The campaign and its year-long.

Mike Mod José Luís Vaquero Cuevas3 days ago

The read model is usually aimed at UI or reporting contexts which implement use case which are not business process related. The Domain needs some queries but they are very specific and at least I'm not a fan of using the read model for that. It very much depends on the domain though.

José Luís Vaquero Cuevas Mike21 hours ago

You said: "Read model [...] implement use case which are not business process"

Not agree with you. I think that the level of abstraction you have to reach in a UI should be high (at domain level) in order to modelling a good task-based UI wich doesn't hide things (read again technical solution vs domain solution in my previous comment) and users and developers should know what will happend when push a button (at a domain level using ubiquitous language) behind the scenes just looking at it. The ubiquitous language is what gives you the query's (for UI) name and description, so, your queries are business related (notice that business related not means business PROCESS related mandatorily).

So, in my opinion, you should use the read model for faster reads and scalability using domain queries because no other kind of query exist.

Remember that this discussion started because I said "Non-domain queries" could be confusing. I know what the author means. He means that those queries doesn't bring back data in which you would apply domain rules and invariants, validation, etc and he called them "Non-domain queries". But this name could be confusing for someone else. I was just trying to clarify this.