CQRS, a look into Axon, getting started

Recently I have been busy developing an app using (among others) the wonderful Axon library. Axon is an implementation of the CQRS pattern, and a pretty good at that.

Axon and CQRS, a first look

The nice thing about Axon and CQRS is that you are completely in control over your db schema. Let’s say you made some evolutionary changes to your domain model and are very happy with it. There is a big chance, however, that an earlier version of your code (and your db schema) is running somewhere for existing users. If you were using a normal (no-CQRS) approach when designing your application, there is a big chance that you’d have to do some migrations of your existing data, for example, by using the Flyway library. This, especially since my changes sometimes are too revolutionary, can be connected with a certain unpleasant amount of manual labor. And here, my fellow reader, is CQRS library like Axon shines: in the ability of the architect/developer to be fully in control of his data. You see, CQRS is all about what happened to your domain and it is up to the programmer to write code that reacts to what happened and turn it into a concrete, dull, user-displayed data.

A quick example

Too abstract? Let’s digress into a quick example. Let’s say we have a user who just changed his username. In a traditional database design you’d have a table User somewhere in your db of choice, it would have a column username, and if it used to be ‘Heisenberg’, it would change into ‘Walter White’. How, when, why it changed, would be forever lost in this simplistic design. For example, if the user was to change his username later back to ‘Heisenberg’, if you, as a developer, didn’t put an auditing framework, like Jboss’s Envers, all that happened would be lost because the end result to the User entity is the same.

The problem with traditional, entity based db design

In the end, using the traditional database design approach if an entity’s attribute changed like from A to B, to A again, if you haven’t been observing that, there is no way to distinguish whether it hadn’t been A all the time.

Traditional db auditing in real-life applications

Of course, in production-ready apps, to solve the problem of ‘the falling tree in the forest‘ , there is a whole layer about auditing, and what you’d get is probably a separate table somewhere called Audit or, UserAudit, where you’d get data like the User’s name changed at this and this time to this and that value. But you, as an architect, would have to design and think about that and its resulting complexity. And unfortunately, designing a system and thinking about its complexity surely doesn’t sound as something that is in the job description of an architect, as we know that most of us guys that go by this job title, more fit the description ‘extremely specialized in going through copious amounts of coffee’.

Seeing things the CQRS way

We since established that we architects are an easygoing folk that would prefer things to be as easy and simple as possible and involving as little thinking as possible. Configuring such an audit system to be robust requires a lot of effort ( speaking from experience ) and even more effort for it to be useful. And once it is setup, if any changes need to be made, it involves even more effort. Herein lies CQRS first big advantage to the traditional database design approach: while normally you have an entity to which ‘things happen’ and it is basically the result of those things, in CQRS it is the other way around: ‘things happen’ and they may (or may not result) in one or multiple entities.

While the two approaches appear deceptively simple, the event-based approach has the distinct advantage that it is inherently versioned and audited. Because while in traditional db approach, if I were to change a property’s name from A to B, to A again, and the resulting entity is the same as in the beginning of the process, in CQRS we would have 3 sequential events: A, B and A, respectively, all pertaining to entity E.

Reaping the benefits

How does that help us, you ask? It  helps us in the sense that we now know what and when happened to entity E (and in Axon, we can attach metadata to each event in order to enrich the contextual information). That means by just applying CQRS our database design becomes inherently auditable and versioned, and we don’t really have to think about that, which, as we established, is a big plus in the world of software architects.

I plan to add some tutorials in the very near future to help readers get started with Axon and CQRS If you guys have anything in particular you want me to talk about, give me a shout and I will try to respond to you as quickly as I can.

2 thoughts on “CQRS, a look into Axon, getting started

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.