Now Aggregate stores its events in local collection. Aggregate will apply events just after their production, not waiting for persistence confirmation. It will work due to syncronious persistence and guarantee from GridDomain that before all events will be persistence, a new command would not be processed by aggregate, and in case of events persistence occurs, the aggregate will be restarted and no state will remain in-memory only.
However, there are a lot of additional options and room to improve.
For example, in the case of async commands, the aggregate can issue events after executing a command and do not apply them until persistence confirmation. It can be combined with requirements for new commands processing before persistence callback, like async command execution.
Add new interfaces for aggregate to implement for such cases, support it by aggregate actor
Now Aggregate stores its events in local collection. Aggregate will apply events just after their production, not waiting for persistence confirmation. It will work due to syncronious persistence and guarantee from GridDomain that before all events will be persistence, a new command would not be processed by aggregate, and in case of events persistence occurs, the aggregate will be restarted and no state will remain in-memory only.
However, there are a lot of additional options and room to improve.
For example, in the case of async commands, the aggregate can issue events after executing a command and do not apply them until persistence confirmation. It can be combined with requirements for new commands processing before persistence callback, like async command execution.
Add new interfaces for aggregate to implement for such cases, support it by aggregate actor