CODEWITHSUNDEEP
domain-driven-designcqrsevent-sourcing
user2558928
user2558928

Reputation: 299

CQRS & Event Sourcing - save commands instead of events?

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?

Upvotes: 4

Views: 1610

Answers (2)

David
David

Reputation: 535

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.

Upvotes: -1

Codescribler
Codescribler

Reputation: 2305

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/

Upvotes: 3

Related Questions