Spring Boot Akka Event Sourcing Starter (Part 2)
Spring Boot Akka Event Sourcing Starter (Part 2)
As we continue this series, we'll dive into the meat of this event sourcing starter to see how it works so you can get Spring and Akka working well together.
Join the DZone community and get the full member experience.Join For Free
Before we start, if you are looking for Part 1 of this series, here it is. Now we will continue in Part 2 to explain the starter itself in more detail:
The Tookit Starter Is an Abstraction for the Following
- How to define persistent entity actors for your aggregate, plus the integration with Spring
- Aggregate flow DSL abstraction for handling commands and events, plus asynchronous command actions. That is not highly recommended, as your aggregate should be your transaction boundary context and should own its contextual data as well.
- A cluster sharding abstraction for your created persistent entities, plus making it configurable via Spring.
- Actor system configuration and integration with Spring Boot.
Let us go over the points mentioned above, and then in Part 3, I will share a complete working example to act as a reference of how to use the event sourcing toolkit starter
The Generic Persistent Entity Class in the Starter
The main abstracted entity class is PersistentEntity: The root entity class.
That extends AbstractPersistentActor from the Akka Persistence toolkit. It has all the common and abstracted technical functionalities for defining persistent actors. That lets you focus on the business flow of your aggregate logic.
The Aggregate Flow DSL Overview
The flow, as mentioned before in Part 1, just abstracts defining a flow of commands and event handling and the responses that need to be sent back to the sender.
When a command is received, the flow context will be initiated with the current state before handling the command and then, based on the defined flow in your aggregate, the command or event will be handled accordingly.
The flow context overview:
The actions that will be generated from flow command handlers or event handlers based on the class diagram above are:
- Persist one generated event, then do a post action.
- Persist a list of generated events, then do a post action.
- There are no generated events to persist. Just do post action, if any (read-only commands case).
The Cluster Sharding Abstraction Into the Toolkit Starter
The two main classes that abstract cluster sharding and do the Spring integration are PersistentEntitySharding and PersistentEntityBroker. You can check the code for more details.
- PersistentEntitySharding abstracts the cluster sharding creation per entity based on its configuration via the starter: code reference.
- PersistentEntityBroker is the broker to get the persistent entity shard in an abstracted way from your calling service by just passing the aggregate class type.
The Actor System Integration With Spring Configuration
There is a specific interface that needs to be extended when you need to configure your entity bean. That is PersistentEntityProperties, where you can configure many properties as shown in the class diagram below. In Part 3, we will see a concrete example of its usage:
- snapshotStateAfter: takes a snapshot of the state after a specifically configured period of time.
- entityPassivateAfter: passivates the entity actor after the configured time.
- tags: the event tags used to tag events before storing them into the event store.
- numberOfshards: configuration of the number of cluster shards for this entity.
- persistentIdPostfix and PersistenceIdProfix: used for the unique aggregate Id within the shard.
- asyncPersistentEntityDispatcherName: the name of the configured Akka dispatcher to be used for the async actions within the aggregate actor.
- pipeDispatcherName: the configured Akka dispatcher name to be used for pipe communication within the aggregate actor.
- scheduledAsyncEntityActionTimeout: the configured timeout for aync action responses waiting to avoid blocking the actor forever.
Then, the last point is the Spring configuration to reference your Akka actor system configuration to be used with the toolkit Spring Boot configuration initialization.
The configuration needs to be prefixed with spring.akka, as seen below, where you need to provide the location of your actor system configuration file and the name of your actor system. In Part 3, we will go through a detailed order management application based on the explained toolkit starter.
// we will see detailed reference for that in part 3 with the working example spring.akka.config: eventSourcing.conf spring.akka.system-name: orderManagerSyste
The GitHub Toolkit and Order Manager sample code are at this link.
Published at DZone with permission of Mahmoud Romeh , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.