We should adjust the EventStore and EventStorageEngine to be in line with the new Unit of Work, ProcessingContext, and MessageStream API (as introduced in #2953).
This would mean the EventStore would become more "async native," allowing a broader set of options when implementing (for us) and utilizing (for us and users) it.
Furthermore, as we've partially done for the CommandBus in PR #3003, we should layer the EventStore and EventStorageEngine into their separate concerns.
By doing so, we increase the modularity and, through that, enhance the flexibility and testability of the separate layers.
This change can go together with an adjusted and dedicated configuration API for event storage. If the scope of the PR increases too much, it would be fair to perform the configuration task in a separate PR.
Lastly, it is paramount we start revamping the APIs to support the dynamic consistency boundary (DCB) that'll come to Axon Server.
With this in place on the EventStore level, we would greatly enhance Axon Framework's capabilities to event source different styles of models.
The EventStore implementations use the old UnitOfWork and cover a lot of topics in a single class.
Added, dynamic consistency boundary support is not included at all.
Wanted Behaviour
The EventStore implementations use the new async-native messaging API and are spread out over several layers.
Lastly, the API should be ready to support the dynamic consistency boundary.
Although snapshotting is a part of the original EventStore, the snapshotting logic will be implemented by another pull request than the base pull request for this issue.
Enhancement Description
We should adjust the
EventStore
andEventStorageEngine
to be in line with the new Unit of Work,ProcessingContext
, andMessageStream
API (as introduced in #2953). This would mean theEventStore
would become more "async native," allowing a broader set of options when implementing (for us) and utilizing (for us and users) it.Furthermore, as we've partially done for the
CommandBus
in PR #3003, we should layer theEventStore
andEventStorageEngine
into their separate concerns. By doing so, we increase the modularity and, through that, enhance the flexibility and testability of the separate layers. This change can go together with an adjusted and dedicated configuration API for event storage. If the scope of the PR increases too much, it would be fair to perform the configuration task in a separate PR.Lastly, it is paramount we start revamping the APIs to support the dynamic consistency boundary (DCB) that'll come to Axon Server. With this in place on the
EventStore
level, we would greatly enhance Axon Framework's capabilities to event source different styles of models.The stateful message handlers and saga revisioning issues are just two examples for which this support is mandatory.
Current Behaviour
The
EventStore
implementations use the oldUnitOfWork
and cover a lot of topics in a single class. Added, dynamic consistency boundary support is not included at all.Wanted Behaviour
The
EventStore
implementations use the new async-native messaging API and are spread out over several layers. Lastly, the API should be ready to support the dynamic consistency boundary.