Intent of commands and events in CQRS w / ES

Question

My question is related to this . Although related questions and answers show why we want to separate them, I wanted to make sure that my understanding of the intention was correct. In all the examples I've seen, it seems that the purpose of the command is that it can be rejected and that it updates the object in memory, and the event then updates the database. Now I know that I am overly simplifying here, but is it right to understand that the commands are designed to update memory and events that update the database? If not, can someone comment on me.

I am trying to learn these patterns, and so I still understand it, and I want to make sure that it is correct. Thanks in advance.

Answer 1

Your understanding is correct.

Commands are issued against the domain model and request specific behavior. The domain model checks to see if execution is allowed and behaves accordingly. Commands can be seen as specific use cases to be performed.

Events, on the other hand, simply announce that something has already happened (they cannot be rejected because you cannot change the past.)

Based on these events, your application (like other applications in the integration scenario) can react accordingly - for example, update the database of a read model.

In particular, when the Sourcing pattern is applied, events are what is stored and played back to update your domain model if necessary.

Answer 2

First of all, I don’t think you are simplifying this too much. This is a simple concept.

Teams tell your application to do something.

Events tell the world that you did something.

If your application cannot do what they are told (due to business rules or for some other reason), it does not. And, in turn, does not announce anything. If he does something, he announces it through an event.

If someone has subscribed to these events and cares about when they happen, then they can update their application with the data in the event.

In practice, this usually means that your readable model subscribes to events and updates them accordingly.

Take the user creation. You issue a User_CreateCommand that contains information about the user. Then the command handler will create a new object, this object will be the user, and save it in the repository. Creating a user launches User_CreatedEvent, which will be processed by your reading model, and the reading model will be updated. Any other listening system can also update itself.

The part that requires a bit of study is that when you save the user to the repository, you actually do not save the user object, as you think. In fact, you save a User_CreatedEvent that contains all the data about the user.

Later, when you need a custom object, you will call something like _repo.GetById (1);

Then all events related to this user will be played back and create a custom object.

Hope that helps :)