Exploring CQRS with Axon Framework: Overview of Some DDD Concepts

In Exploring the Commands, Command Bus and Command Handler, we looked at the command handling aspect of CQRS using Axon. We created commands that were dispatched into a command bus via a command gateway, which were then subsequently handled by their respective command handlers.

But in that post, all the command handlers did was to print to the console. In real life applications, you would want the commands to lead to state change within your application. Achieving this is what we look into next, but for us to do that, we would first need to explore some concepts that stem from the Domain Driven Design world. Namely Entities, Aggregates, Aggregate Roots, Repositories and Domain Events.

At this junction, it is worth mentioning that concepts and ideas from DDD always pop up in a typical CQRS discussion...this post and others in the series are not an exception, therefore, at least a basic understanding of these DDD concepts will be beneficiary.

This post will provide a quick overview of the relevant DDD concepts without touching on Axon Framework, while the next post will look at how Axon is used for their implementation.

That been said, let us quickly have an overview of the relevant DDD concepts that we will be needing in our exploration of CQRS with the Axon Framework.

Domain Driven Design.

The core philosophy/objective of DDD is meant to provide a means to successfully manage the inherent and unavoidable complexity involved in building software.

In order to do just that, it prescribes a couple of things, one of which is that software components should model, as much as possible, the domain it is built for. It then prescribes methodology and building blocks that may help in doing that. Entity, Domain Events, Aggregate, Aggregate Root, Repository and Domain Events are a few of these components, and they are the ones we would touch on, as they directly come into play in our exploration of CQRS.

Domain Objects

The term “domain objects” isn't anything spectacularly technical. It is just a term that refers to the different kinds of objects used to model the domain which a software is being built around.

Entity

Entities are objects with the distinguishing characteristics that they hold an identity that form a thread of continuity.

For example looking at this object:

class Person {
 firstName,
        lastName,
        age,
        socialSecurityNumber
}

Holding a thread of continuity refers to the fact that in the life cycle of the Person object, its various properties may change, but the one that establishes its identity would always remain the same. A person may change their name, get older etc, but their socialSecurityNumber is kept constant.

In DDD, entities are also advised to hold the business logic, and not just be a bag of data

Aggregate and Aggregate Root

Aggregate is technically a "concept" and not a file, a class, or a thing you can readily point to in an IDE…It is more of an abstract concept than it is a concrete thing.

It is a logical collection of domain objects, that should form an atomic and cohesive whole.

Two characteristics of this kind of object collection is that they should form a logical grouping and the constituent objects should be kept in a defined, required consistent state.

An example is a vehicle which is made up of various objects: tyres, steering wheel, a radiator, an engine etc but it makes sense to take all these constituent objects as an atomic whole that should always be kept in a consistent state (well atleast if they are to belong to the same vehicle).

Such a collection of objects is what is referred to as an Aggregate in DDD.

The Aggregate Root on the other hand, refers to the object amongst these cohesive group that has been designated to be the container object. It is the Aggregate Root that ensures the collection of objects are kept in the required consistent and cohesive state.

Using our vehicle analogy we can have a Car object as the aggregate root. And if you want to operate on a tyre, you do not have access to the tyres directly but have to go through the Car object.

You won’t find an “Aggregate” as a “class” if you go looking for one in a system designed with DDD, what you would most likely find is a collection of objects with one of the objects assigned to be the root of that object...aka the aggregate root.

In real life systems, an aggregate root would contain many objects, and in simpler systems, the aggregate root itself may be all the object that needs to exist. In such a case, you have the aggregate root as the only object in the aggregate

Repository

Repository is also an object. It is the domain object that is meant to abstract away the retrieving and the persisting of aggregates.

So in Domain Driven Design palace, you do not access aggregates directly, but you do so via a Repository.

Domain Events

The concept of domain event arises from the desire to have fully encapsulated subsystems within a bigger system in domain driven design. Domain events are meant to be the bridge between two encapsulated system that should not have direct dependency on each other but still needs to work together.

Domain Events are thus messages that convey information to the outside world, about changes that has occurred in an aggregate.

Next Up

Domain Driven Design is a very extensive topic. There is a tome of a book Domain-driven design that has been written only for its exploration. So these few concepts that was explained in this post does not, in any way cover the full depth of what DDD is about, but what it does (and I hope well enough) it to provide with a basic understanding, so when it comes to using Axon to build Aggregate Roots, Repositories, etc, the reader can have a better understanding of what is going on.

The next post will then be Building the Entity, Aggregate, Aggregate Root and Repository components. In the post we see how we use the Axon Framework to actually build the components within our CQRS application.