Last week, at this year’s JAX London conference, I gave a talk about the General Data Protection Regulation (GDPR), and the very interesting and specific implications for applications that use event sourcing. The talk was inspired and partly based on two earlier articles that I wrote: Forget me please? Event sourcing and the GDPR and Event sourcing and the GDPR: a follow-up.
axon
Rebuilding projections in Axon Framework 3
CQRS (Command Query Responsibility Segregation) allows you to have separate models for reading and writing. Combining that pattern with Event Sourcing leads to a powerful capability: updating query (read) models, based on events. In real-time or rebuilding them from an existing collection of events. This post focuses on such projections, in applications that are built on Axon Framework.
Upcasters or a versioned event store: pros and cons
In a previous article, I wrote a few things about upcasters. One of the significant downsides when implementing an upcaster is that it adds to our application’s technical debt. An alternative technique is the versioned event store (or versioned event stream), where the existing event store is copied and modified. In this post I’ll discuss the pros and cons of both approaches.
Forget me please? Event sourcing and the GDPR
In May 2018, a new piece of EU legislation called the General Data Protection Regulation (GDPR) will come into effect. The GDPR attempts to regulate data protection for individuals within the EU and has very interesting and specific implications for applications that use event sourcing. In this article, I’ll discuss my thoughts on this subject and a few pointers for those implications.
Concurrent commands in event sourcing
In this post I want to talk a little about concurrency in the context of CQRS and event sourcing. Specifically, when a single aggregate is concurrently accessed by two commands (or command handlers, really). Read more
Event versioning (or why I sometimes modify the event store)
Requirements and applications evolve and change, leading to refactoring. For example, user registration now requires a first and last name, what was once an error may no longer be considered one, etc. In an event sourced application, that poses a few problems. In this post I’ll discuss a few strategies and my views on event versioning.
Distributed command handling with Axon, JGroups and Docker
In a recent project I used Axon Framework together with JGroups, to create a clustered, or distributed command bus.
In that project we had some concurrency issues. One of those issues was that two events were applied on a single aggregate with an identical sequence number. The JGroupsConnector in Axon uses a consistent hashing algorithm to route commands. This ensures that commands with the same routing key will be sent to the same member, regardless of the sending member of that message. Within the project we used the aggregate identifier as the routing key, ensuring that commands for a single aggregate are processed in a single JVM, thus preventing duplicate sequence numbers.
To demonstrate such a setup, I’ve created a simple demo application, based on the latest version of Axon Framework (3.0-M3). Using Docker Compose, the application is launched twice (in two containers). The containers should then form a JGroups cluster, and handle a number of commands. Go check it out on GitHub!