CQRS & Event Sourcing - save commands instead of events?

Question

I'm new to CQRS and event sourcing, but maybe someone can help me.

Shortly: I take a command object to something like an aggregate. The aggregate generate an event, which stored in a repository. Now I can use this event to rebuild the aggregate to the current state. Is that correct?

And now to my consideration: Isn't it easier to save the commands? If I have one create-command and five update-commands, I can rebuild my aggregate by execute the six commands on an empty aggregate. I don't need to handle commands AND events to generate aggregates.

The events can also be used as domain events, but I don't need they for event sourcing.

What is the advantage to use event sourcing instead of my approach?

Answer 1

I will not answer what the advantage of event sourcing is but I think it is important to think about what you want to achieve, where commands come from and when you need to store commands in addition to events.

What you want to achieve? If you want to apply all the commands that your service version 1.0 received in production to your newly developed version 1.1 then you need the commands. You would do that for example to test the service functionality or performance.

Where commands come from? Commands are created based on events, by the UI, by other applications that do not publish events, ...

When to store commands in addition to events? If the goal is to simulate the same environment as in production then you need a record of all inputs. So you need all commands. If you would not store commands from the UI then you would not have those. So it might be of advantage to store commands if there is no event that generated the command or if you did not store it. For consistency, instead of storing a ChangeUserCommand you could store a HttpRequestReceivedEvent that contains the command together with additional data from the request.