Different ways to Record Events
Two ways of setting up Event Sourced Aggregates
There are two ways we can configure our Aggregate to record Events.
1) Pure Event Sourced Aggregate
This way of handling events does allow for pure functions. This means that actions called on the Aggregate returns Events and are not changing internal state of Aggregate.
EventSourcingAggregate
andIdentifier
works exactly the same as State-Stored Aggregate.Event Sourced Aggregate must provide version. You may leave it to
Ecotone
usingWithAggregateVersioning
or you can implement it yourself.CommandHandler
for event sourcing returns events generated by specific method. This will be passed to theRepository
to be stored.EventSourcingHandler
is method responsible for reconstructingAggregate
from previously created events. At least one event need to be handled in order to provideIdentifier
.
2) Internal Recorder Aggregate
This way of handling events allow for similarity with State Stored Aggregates. This convention requires changing internal state of Aggregate to record Events. Therefore Pure ES Aggregate is recommended as it's not require for any internal state changes in most of the scenarios. However ES Aggregate with Internal Recorder may be useful for projects migrating with other solutions, or when our team is heavily used to working this way.
In order to make use of alternative way of handling events, we need to provide trait WithEvents.
Command Handlers instead of returning events are acting the same as State Stored Aggregates. All events which will be published using
recordThat
will be passed to theRepository
to be stored.
Last updated