In Event Store / CQRS architecture, why are events stored instead of commands?

Question

Presumably we could resurrect state by applying the same set of commands, so why not simply store commands rather than events?

Banket

Answer 1

Events, communicate "this happened in our system". Events occur when a command has been accepted and processed. No one can reject or change the fact that it happened. It's the only authoritative source of changes in the system

Commands are just a way for a part of the system (like a UI) to tell the component in charge of making changes to the system (the "command handler") what it wants done. However, the command handler can choose not to process the command for various reasons. The UI could have stale information and processing the command wouldn't make business sense or the user could have not had the privileges to perform that action. Either way, the command is really just a request & have no bearing on the state of a system

.

Leclerc

Plus, re-execution of commands would be destructive (affect data). For re-execution of commands to work, you would have to have the same initial state. Events, by definition, are not destructive. – Misuse

I know that I'm a little late to the party, but isn't the whole point of event store to recreate application state? Isn't the request of a command in itself an event? – Glottalized

@Glottalized No a command is something to perform. An event is something that happened. When we handle a command, business logic takes place, in order to create events. Events are handle that then we make our projections off of. Command = something to happen, Events = something that has happened. If we were to store events and "reply them" the resulting events could be completely different if we changed our business logic. If we want to change our project (current state/model) we can absolutely do that, but we do that by replaying events. Something that has happened cannot be changed – Butadiene

@Butadiene why we cannot take the command, validate it, and only if it's valid, then store it in the stream? If it's stored in the stream then it became a fact (Event). – Jimenez

@LeonardoMangano A command is an intent, and events are the results of that intent. A command will be received and depending on your logic 1 or more events will be fired off from that, perhaps at once of from a chain. If you were to change your logic and rerun your commands, your system would be completely different. Different NEW events will be fired. You cant change the past. you can only interpret it differently. so commands cant be rerun. you can store them and that might be useful in different ways, but they cant be used in a stream, to build up an aggregate from. only events can – Butadiene

@Butadiene if command handlers in aggregates are pure functions, why you say that if you rerun them, they will produce a different result? – Jimenez

@LeonardoMangano that statement doesnt seem to make sense to me. - A command is an intent (e.g. create order) - An aggregate is a model that ensures some domain rules/business logic (e.g. an order and will have functions to perform actions on that will spawn events) - A command handler is a handler that will handle that command. This will run the actions in the aggregate and also handle any application logic. A command for create order might be handled by constructing an aggregate, saving those events to the stream and then calling an application service to create an email. – Butadiene

so if you were to rerun a command it will push new events to your streams and persistence and also any other application services, e.g. firing a new email to a customer about an old order. Not only that if the code was to change in the command handler than to the previous time you called it, the outcome could be different. dont change the past. the past is done. that what are event are the record of. so you rerun events. – Butadiene

@Master2 thanks for the explanation, It makes sense – Jimenez

Answer 2

"Stream of Commands" can be processed by your app to produce "Stream of Events", which can produce "Current data".

It certainly is possible to store commands, but the question is why would you do that?

Some possible answers include, the command itself is useful data. You might want to know how many times user tried to add items to their cart (command), even though no more items are added (events) after the cart is full. Granted, this can be solved with just another event, possibly named "Item Added Although Cart Is Full"

In that light, commands are events. Which you process with your business logic to produce another stream of events, lets call them State events. Which you can possibly create another stream, or project onto a relational data structure, or whatever. Adding command could possibly add complexity, at the benefit of more data. Just like how Event Sourcing itself is a step higher than traditional "Current state" data stores.

Edit: The above clears out the terminologies and purpose.

Conclusion: Commands = CommandGivenEvents, "Events" = BusinessLogicProcessedAndStoredEvents. Different purposes. Like how if you change your event handlers, the projected data will be different. If you change business logic, the Commands will produce a different Event Stream. One step higher.

Dabchick