Edition 0 Updated to asp. Net core 0

Use message queues (out-of-
proc) in the command’s pipeline
 
Another choice is to use asynchronous messages based on brokers or message queues, as shown in 
Figure 7-26. That option could also be combined with the mediator component right before the 
command handler. 
Figure 7-26. Using message queues (out of the process and inter-process communication) with CQRS commands 
Command’s pipeline can also be handled by a high availability message queue to deliver the 
commands to the appropriate handler. Using message queues to accept the commands can further 
complicate your command’s pipeline, because you will probably need to split the pipeline into two 
processes connected through the external message queue. Still, it should be used if you need to have 
improved scalability and performance based on asynchronous messaging. Consider that in the case of 
Figure 7-26, the controller just posts the command message into the queue and returns. Then the 
command handlers process the messages at their own pace. That is a great benefit of queues: the 
message queue can act as a buffer in cases when hyper scalability is needed, such as for stocks or any 
other scenario with a high volume of ingress data. 
However, because of the asynchronous nature of message queues, you need to figure out how to 
communicate with the client application about the success or failure of the command’s process. As a 
rule, you should never use “fire and forget” commands. Every business application needs to know if a 
command was processed successfully, or at least validated and accepted. 
Thus, being able to respond to the client after validating a command message that was submitted to 
an asynchronous queue adds complexity to your system, as compared to an in-process command 
process that returns the operation’s result aft
er running the transaction. Using queues, you might 
need to return the result of the command process through other operation result messages, which will 
require additional components and custom communication in your system. 

---

282 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
Additionally, async commands are one-way commands, which in many cases might not be needed, as 
is explained in the following interesting exchange between Burtsev Alexey and Greg Young in an 
online conversation
: 
[Burtsev Alexey] I find lots of code where people use async command handling or one-way command 
messaging without any reason to do so (they are not doing some long operation, they are not 
executing external async code, they do not even cross-application boundary to be using message 
bus). Why do they introduce this unnecessary complexity? And actually, I haven’t seen a CQRS code 
example with blocking command handlers so far, though it will work just fine in most cases. 
[Greg Young] […] an asynchronous command doesn’t exist; it’s actually another event. If I must accept 
what you send me and raise an event if I disagree, it’s no longer you telling me to do something [that 
is, it’s not a command]. It’s you telling me something has been done. This seems like a slight 
difference at first, but it has many implications. 
Asynchronous commands greatly increase the complexity of a system, because there is no simple way 
to indicate failures. Therefore, asynchronous commands are not recommended other than when 
scaling requirements are needed or in special cases when communicating the internal microservices 
through messaging. In those cases, you must design a separate reporting and recovery system for 
failures. 
In the initial version of eShopOnContainers, it was decided to use synchronous command processing, 
started from HTTP requests and driven by the Mediator pattern. That easily allows you to return the 
success or failure of the process, as in the 
CreateOrderCommandHandler
 implementation. 
In any case, this should be a decision based on your application’s or microservice’s business 
requirements.