1 - Can someone explain, why in AKKA Persistent Actors, updating the state is done after its event is recorded ?
1.1 - What would happen if before the update state "callback" happen, the system crash ?
(I think I kind of get it but my confusion comes from how i am not able to understand the handling of a Command. I don't see it as something different from handling an Event. see below)
2 - Is there a difference between the execution/handling of a Command and the "update state callBack" which is to be related to the handling of an event.
2.1 - In other words, where should go the handling of the Command, and where should go the handling of the event. Are those two "handlings" necessarily different.
All the examples that i have seen mostly shows that there is nothing specific about handling a command other than validating it and then persisting its associated event and updating the actor state accordingly.
This means that handling a command is somewhat handling an event after all. This means that the vent can't be recor
My confusion comes the fact that, an event can only record something that has happened. But in all the examples that i have seen, upon receiving a command, nothing particular happens, if it is just actually, setting the event that the action was executed (which one ?) and then updating the state. This somewhat reverse the logic of things.
If the command is create an order, then we would have automatically, probably after validation, that an order_was_created, and then after an updated state function that would update the state of the actor according to the event receive.
It just feels strange. SO in a sense, a Command, aside from being validated, never triggers anything, especially if it has to do with updating something, but place an event which then will trigger the real work.
So a Command is here to simply say if an event as happened, where this event will actually made a reality after. That is, it is done after for recovery purpose.
It is confusing
A command is a request to change data. An event is an applied change and after the fact. Changes to data are validated prior to journaling the event. A journaled event is considered a guaranteed successful update because it is persisted after validations have been applied. When the persistent actor rehydrates, it replays all the changes and the state is updated accordingly with the guarantee that all updates can be applied. This is the basic reason why the state is applied afterwards. The pattern you are seeing is known as Event Sourcing. I think this presentation explains it well.