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

Spring Boot Akka Event Sourcing Starter (Part 1)

DZone's Guide to

Spring Boot Akka Event Sourcing Starter (Part 1)

Check out this custom toolkit that aims at combining the power of Spring Boot and Akka Persistence with an eye on event sourcing, DDD, and CQRS.

· Java Zone ·
Free Resource

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

Here, I am going to share a custom toolkit wrapped as a Spring Boot project with an Akka Persistence starter to act as a ready-made toolkit for event-driven, asynchronous, non-blocking flow APIs, event sourcing, and CQRS implementation within Spring Boot services. We will cover the following:

  1. Overview of the toolkit for DDD, event sourcing, and CQRS implementation.
  2. The integration between Akka Persistence and Spring Boot via a starter implementation with a lot of abstraction for abstract entity aggregates, cluster sharding, integration testing, and flow definition.
  3. A working application example that showcases how it can be used.
  4. Summary of possible designs.
  5. What is next and special remarks.

The Overview

Before going through the toolkit implementation, if you are not already practiced in the concepts, you should go over domain driven design, event sourcing, and CQRS principles. Here is one good URL that can help you to get a nice overview of the pros and cons of that style of design and when you need it.

Instead of implementing those patterns from scratch, I have decided to use Akka Persistence to apply the core principles of event sourcing, plus my layer above it, to abstract out defining your aggregate with its command and event-handling flow.

Within the toolkit, the Aggregate command and flow handling will be as follows:

Aggregate flow(3).png

The flow definition API is as follows:

  • There are state-changing command handler flow definitions, which match the command class type to a specific command handler.
  • There are event handlers that match event class types to an event handler, which will do the related logic of that event triggering
  • There are read only command handlers that do not change the state of the aggregate entity. It can be used for query actions or other actions that do not mutate the entity state by appending new events.

So the flow API's different semantic branches are:

  1. If the Command message is received:
    • Is the command transactional:
      1. Get the related command handler for that command type based on the flow API definition for that aggregate and the related current flow context with the current aggregate state.
      2. Execute the command handler logic, which will trigger one of the following 2 cases:
        • A single event to be persisted. Then, any configurable post action to be executed after persisting the event to the event store (like post processing and sending back a response to the sender).
        • A list of events to be persisted. Then, any configurable post action to be executed after persisting the event to the event store (like post processing and sending back a response to the sender).
    • If the command is read only:
      • Just execute the configurable command handler for it based on the flow API definition for that aggregate and the related current flow context with the current aggregate state. Then, execute any configurable post-processing actions.
  2. If the Event message is received:
    • Get the related event handler based on the defined flow for the aggregate, then execute it against the current flow context and aggregate state.
  3. If the Stop message is received:
    • It will trigger a safe stop flow for the aggregate entity actor.
  4. If the Receive Time-Out message is received:
    • It will be received when there is an ASYNC flow executed for a command and the waiting for response mode of the aggregate entity actor is timed-out. That is to avoid blocking the actor for a long time, which can cause starvation and performance issues.

In Part 2, we will cover the Spring Boot Akka event sourcing starter details, which will cover the following:

  1. Smooth integration between Akka Persistence and Spring Boot.
  2. Generic DSL for the aggregate flow definition for commands and events.
  3. How to abstract aggregate persistent entity actors with all the common logic in place. The idea is that they can be used with a concrete managed Spring Beans implementation of different aggregate entities.
  4. Abstract cluster sharding run-time configuration and access via Spring Boot custom configuration and a generic entity broker that abstract the cluster shading implementation for you.

And here is the GitHub toolkit project link.

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

Topics:
spring boot ,event sourcing ,cqrs ,domain driven design ,java ,tutorial ,akka persistence

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}