Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Spring Boot Akka Event Sourcing Starter (Part 2)

DZone's Guide to

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.

· Java Zone ·
Free Resource

Learn how to build stream processing applications in Java-includes reference application. Brought to you in partnership with Hazelcast.

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:

FlowContext

The Tookit Starter Is an Abstraction for the Following

  1. How to define persistent entity actors for your aggregate, plus the integration with Spring
  2. 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.
  3. A cluster sharding abstraction for your created persistent entities, plus making it configurable via Spring.
  4. 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:

Screen Shot 2018-04-23 at 12.49.14.png

The actions that will be generated from flow command handlers or event handlers based on the class diagram above are:

  1. Persist one generated event, then do a post action.
  2. Persist a list of generated events, then do a post action.
  3. There are no generated events to persist. Just do post action, if any (read-only commands case).

Screen Shot 2018-04-23 at 12.48.52.png

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.

Screen Shot 2018-04-23 at 12.57.50

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:

Screen Shot 2018-04-23 at 13.07.47.png

  1. snapshotStateAfter: takes a snapshot of the state after a specifically configured period of time.
  2. entityPassivateAfter: passivates the entity actor after the configured time.
  3. tags: the event tags used to tag events before storing them into the event store.
  4. numberOfshards: configuration of the number of cluster shards for this entity.
  5. persistentIdPostfix and PersistenceIdProfix: used for the unique aggregate Id within the shard.
  6. asyncPersistentEntityDispatcherName: the name of the configured Akka dispatcher to be used for the async actions within the aggregate actor.
  7. pipeDispatcherName: the configured Akka dispatcher name to be used for pipe communication within the aggregate actor.
  8. 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.

Learn how to build distributed stream processing applications in Java that elastically scale to meet demand- includes reference application.  Brought to you in partnership with Hazelcast.

Topics:
spring boot ,akka ,event sourcing ,cqrs ,java ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}