CODEWITHSUNDEEP
design-patternscqrsevent-sourcing
Erick T
Erick T

Reputation: 7449

What are the advantages to storing commands in a CQRS/ES system?

I am working on a CQRS/event store system. At the moment, the pattern that I use is for commands to be synchronous. That is, the user interface does not show an operation as completed until the command is complete, and the success/failure is shown to the user. During execution of the commands, all events generated (e.g., action X occurred on aggregate root Y) are stored in durable storage.

All of the descriptions of CQRS that I have read implement command storage. I am wondering if this is needed in my situation.

One other note - there are a lot of long running command type actions, so I have broken up operations into a command that generates events, and the events in turn issue more commands. The commands are idempotent, based on the state of the aggregate root. I don't know how this would impact the answer, but it is worth pointing out.

Upvotes: 7

Views: 1256

Answers (2)

Yevhen Bobrov
Yevhen Bobrov

Reputation: 706

  1. Regression testing After every dev iteration you can grab command log from production environment, re-execute it and compare event stream produced with one on production. If they different - you have regression in your logic.

  2. Message flow visualization and analysis.

Upvotes: 8

Chris Moutray
Chris Moutray

Reputation: 18369

The examples of Cqrs that i've seen without event sourcing are usual relational databases that store the state of the system rather than Events which show how the state of the data came about. "Command sourcing" is a new concept for me and doesn't seem right since command handlers can change over time. Any changes to the command handlers logic would probably result in commands failing when replayed. Replaying events doesn't have this problem since your objects properties are directly set.

Upvotes: 4

Related Questions