Using query model in command handler/domain services

Question

Should I use the Query model to combine/check certain aggregate information, like in a domain service? I've seen this in a lot of examples. But what if the query data is propagated asynchronously, as a result of a domain event?

Example: a messages board with a User aggregate and a Message aggregate (decoupled for a smaller trx boundary). When a User is marked-deleted, all his Messages need to be marked-deleted as well. This will be done by handling the UserMarkedDeletedEvent within a MessageEventHandler kind of service. Now this service needs to fire DeleteMessageCommands for every Message with the specific User. In order to find the messages, a query is required. I guess this must be done on the read-model, which could be outdated due to asynchronous updates... (I guess the only option is read/query model in case of Event Sourcing)

Answer 1

It is ok to do this just in case of performance. But you should know what you are really asking the read model and what does it mean.

Depending on your domain there could be states that will never change or going back once reached. If you ask the read model for one of this states, then you can state that this is the truth.

But with this you can only state that a command is invalid or maybe valid. The real truth is in the aggregate.

Example:

The foo aggregate can - once deleted - never be undeleted (rule of the domain) and this state is in the read model. If you get this deleted state from the read model, then you can say, that a command - only valid for not deleted foos - is invalid. But you cannot state that it is a valid command, because maybe the aggregate is already deleted and not written to the read model.