Skip to main content
Tweeted twitter.com/StackProgrammer/status/736285217351176192
Added example scenario.
Source Link
magnus
  • 674
  • 1
  • 5
  • 14

In CQRS/ES, a command is sent from the client to the server and routed to the appropriate command handler. That command handler loads an aggregate from its repository, and calls some method on it, and saves it back to the repository. Events are generated. An event handler/saga/process manager can listen to these events in order to issue commands.

So, commands (input) produce events (output), which can then feed back into the system more commands (input). Now, is it common practice for a command to not emit any events, but rather to enqueue another command? Such an approach could be used to force execution in an external process.

EDIT:

The specific use case that I have in mind is the processing of payment details. The client submits a PayInvoice command, whose payload includes the user's credit card details. The PayInvoiceHandler passes a MakeInvoicePayment command to a separate process, which is responsible for interacting with the payment gateway. If the payment is successful, an InvoicePaid event is generated. If for some reason the system crashes after the PayInvoice command is persisted but before the MakeInvoicePayment command is persisted, we can track this manually (no payment will have gone through). If the system crashes after the MakeInvoicePayment command is persisted but before the InvoicePaid event is persisted, we may have a situation where the user's credit card is charged but the invoice is not flagged as having been paid. In that case, the situation would have to be manually investigated and the invoice manually marked as paid.

In CQRS/ES, a command is sent from the client to the server and routed to the appropriate command handler. That command handler loads an aggregate from its repository, and calls some method on it, and saves it back to the repository. Events are generated. An event handler/saga/process manager can listen to these events in order to issue commands.

So, commands (input) produce events (output), which can then feed back into the system more commands (input). Now, is it common practice for a command to not emit any events, but rather to enqueue another command? Such an approach could be used to force execution in an external process.

In CQRS/ES, a command is sent from the client to the server and routed to the appropriate command handler. That command handler loads an aggregate from its repository, and calls some method on it, and saves it back to the repository. Events are generated. An event handler/saga/process manager can listen to these events in order to issue commands.

So, commands (input) produce events (output), which can then feed back into the system more commands (input). Now, is it common practice for a command to not emit any events, but rather to enqueue another command? Such an approach could be used to force execution in an external process.

EDIT:

The specific use case that I have in mind is the processing of payment details. The client submits a PayInvoice command, whose payload includes the user's credit card details. The PayInvoiceHandler passes a MakeInvoicePayment command to a separate process, which is responsible for interacting with the payment gateway. If the payment is successful, an InvoicePaid event is generated. If for some reason the system crashes after the PayInvoice command is persisted but before the MakeInvoicePayment command is persisted, we can track this manually (no payment will have gone through). If the system crashes after the MakeInvoicePayment command is persisted but before the InvoicePaid event is persisted, we may have a situation where the user's credit card is charged but the invoice is not flagged as having been paid. In that case, the situation would have to be manually investigated and the invoice manually marked as paid.

Source Link
magnus
  • 674
  • 1
  • 5
  • 14

In CQRS/ES, can a command create another command?

In CQRS/ES, a command is sent from the client to the server and routed to the appropriate command handler. That command handler loads an aggregate from its repository, and calls some method on it, and saves it back to the repository. Events are generated. An event handler/saga/process manager can listen to these events in order to issue commands.

So, commands (input) produce events (output), which can then feed back into the system more commands (input). Now, is it common practice for a command to not emit any events, but rather to enqueue another command? Such an approach could be used to force execution in an external process.