search

AxonFramework / AxonFramework

Framework for Evolutionary Message-Driven Microservices on the JVM
https://axoniq.io/
Apache License 2.0
3.32k stars 790 forks source link

[#3101] Revise the Event Store - `SimpleEventStore`, `EventStoreTransaction`, `StreamableEventSource`, `IndexedEventMessage` #3131

Open smcvb opened 3 weeks ago

smcvb commented 3 weeks ago

This (draft) pull request provides a very extensive addition to the Event Store infrastructure of Axon Framework. Note that this pull request does not remove the old implementation; it intentionally resides next to it to ensure all infrastructure that should still be adjusted keeps working.

Implementation Description

The new EventStore interface only has a single method right now, which returns an existing or creates a new EventStoreTransaction. When returning or creating an EventStoreTransaction, the user is required to provide a String context (referring to a bounded context for example) and a ProcessingContext. The EventStoreTransaction allows for sourcing and appending of events. For the latter, callbacks can be added to have the user of the transaction react accordingly.

For streaming events, a StreamableEventSource (inspired by the StreamableMessageSource<M> interface) is used, providing functionality to stream events and create TrackingTokens. There currently is a single implementation of the new EventStore interface and the StreamableEventSource called the SimpleEventStore.

The SimpleEventStore expects all its methods to be invoked for a specific (bounded) context. When the contexts match, the operation is passed along to the new EventStorageEngine interface. This new EventStorageEngine for now has a single implementation for in-memory storage.

When sourcing events, a SourcingCondition should be provided to the new EventStorageEngine. This SourcingCondition has an EventCriteria, a start, and an end (both of type long). When appending events, an AppendCondition should be provided to the new EventStorageEngine. This AppendCondition has an EventCriteria and a consistency marker (of type long). When streaming events, a StreamingCondition should be provided to the new EventStorageEngine. The StreamingCondition has an EventCriteria and a position (of type TrackingToken).

As stated above, the new sourcing, appending, and streaming API, expects classes that carry an EventCriteria. This EventCriteria will contain 0..N Index instances, as well as define a number of (event) types. From the perspective of sourcing and streaming, the EventCriteria (and thus the ...Condition interfaces) utilize the Index to filter the returned MessageStream of events. From the perspective of appending, the Indices in the AppendCondition are used to validate if there are matching events present after the AppendCondition#consistencyMarker. In doing so, appending can protect the consistency boundary of a model.

To be able to perform this filter for reading and writing, the EventStorageEngine should store events together with these Indices. To that end, this pull request introduces the IndexedEventMessage, which is a combination of the EventMessage and a Set<Index>.

The AppendCondition, EventCriteria, Index, SourcingCondition, and StreamingCondition all have numerous implementations and helper methods to make them functional. Furthermore, the new EventSourcingRepository introduced earlier uses the new EventStore API as of this pull request to prove the new API. Lastly, I have included a SimpleEventStoreTestSuite, that can be reused as soon as we have additional storage solutions available.

TODO

The following things are not covered in this pull request:

  1. There is no new EventBus interface, nor is the existing EventBus interface implemented by the new infrastructure components -> #3143
  2. There is no new SubscribableMessageSource interface, nor is the existing SubscribableMessageSource interface implemented by the new infrastructure components -> Will be done in another PR mentioning #3101.
  3. The sliding-window cache of the EmbeddedEventStore is no longer present in the SimpleEventStore -> Work described in issue #3135
  4. JPA implementation of the new event storage engine API -> Will be done in another PR mentioning #3101.
  5. JDBC implementation of the new event storage engine API -> Will be done in another PR mentioning #3101.
  6. Axon Server implementation of the new event storage engine API -> Will be done in another PR mentioning #3101.

Next to the above, the code contains numerous TODOs. All TODOs carry an issue number, except the rename/remove TODOs when the hold Event Store infrastructure can be replaced.

sonarcloud[bot] commented 1 week ago

Quality Gate Failed Quality Gate failed

Failed conditions
79.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud