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?
Good question. There are a few reasons. I'll cover just two. The first is more conceptual and the second a bit more concrete.
Conceptually you are storing what changed as a result of a command. What actually happened. As the application progresses through its life cycle you may well change how you handle commands. You may even change what events are created. So if you only have the command you cannot guarantee you will be able to recover the state of an aggregate.
You will also have problems if you ever need to replay your events. Lets say you need to create a new read model based on past events. But if you don't have them you won't be able to. Also you wouldn't want a system to actually do all the things commands make them do when rebuilding an aggregate or creating new read models. For example lets say an email gets sent in the normal processing of a particular command. You don't want that email to be sent every time you rebuild an aggregate.
Hope that makes sense.
Also - beware of 'create' 'read' update' commands. That sounds like a code smell. Check out https://danielwhittaker.me/2014/10/18/6-code-smells-cqrs-events-avoid/