CQRS - Multiple command/query-handlers inside eachother

Question

Is it a good practice in CQRS to use multiple queryhandlers and/or commandhandlers in each other? Or should you only have one per use-case?

• Commandhandlers in a commandhandler
• Queryhandlers in a commandhandler
• Queryhandlers in a queryhandler
• Commandhandlers in a queryhandler -> personally, I wouldn't do this, because you won't expect a query should change data... Correct?

Answer 1

CQRS is an architectural pattern of applying the Single Responsibility Principle which separates the querying from command processing by providing two models(read and write models) instead of one. Thus, it will be a wrong use of the pattern if you use multiple queryhandlers and/or commandhandlers in each other.

This pattern can enable you to scale if you have a very high number of reads. Thus, it is also not an architectural pattern to apply in all bounded contexts of a system.

Answer 2

No, I don't think so.

It's a bad practice, because such way ignores two main advantages of CQRS. First is simple code support and clear structure, because you have separated business logic and queries (aggregated data for visualization).

Second advantage is in scaling. One instance handles commands, and another 5 processes requests. So in theory command code and queries can be executed on different servers. Similarly different queries may be executed on different servers, so including code of commands and queries to each other is bad idea - scaling will be a great pain.

Some CQRS libraries event segregate C & Q sides in different packages, for example here.

Answer 3

Bad idea. If the handler has to do many things such call different databases, 3rd parties, external files, etc Then it SHOULD delegate this to others such repositories, etc.