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.
Dostları ilə paylaş: