Exploring CQRS with Axon Framework: Building the Entity, Aggregate, Aggregate Root and Repository Components

The previous post provided a basic explanation of Entity, Aggregate, Aggregate Root, Repository and Domain Events which are some of the building blocks in Domain Driven Design. This post looks at using Axon Framework to create some of these building blocks.

In Exploring the Commands, Command Bus and Command Handler, we looked at the command handling aspect of CQRS using Axon, where we had commands created, 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 what the command handlers did was to print to the console. In real life applications, you would want the commands to lead to some business logic being executed, which might lead to state change in the application.

Achieving that, is what we look into in this post.

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.

Exploring CQRS with Axon Framework: The Command, Command Bus and Command Handling Components

In this post we look at how to use Axon Framework to build out the command handling parts in a CQRS application.

It is part of a series of post that explores CQRS with Axon Framework.

As stated in the introductory post, these series of post is accompanied by the exploringCQRSwithAxon  project on Github. The project is a trivial application that simulates two bank accounts. It will support debiting, crediting and transfer between these two accounts. It is intended to help illustrate the features discussed as we explore how Axon Framework can be used to build application following CQRS stipulations.

The sample application is built with Axon Framework and Spring Boot. It uses the 2.4.1 version of Axon Framework, as you will notice in the Pom.xml

<dependency>
   <groupId>org.axonframework</groupId>
   <artifactId>axon-core</artifactId>
   <version>2.4.1</version>
  </dependency>
  <dependency>
   <groupId>org.axonframework</groupId>
   <artifactId>axon-test</artifactId>
   <version>2.4.1</version>
   <scope>test</scope>
  </dependency>

For the purpose of this series we would be using only the axon-core and axon-test modules.

Exploring CQRS Architecture with Axon Framework: Introduction

This is a first post in a series of posts that explores the CQRS architecture with Axon Framework.

The aim is to first understand what CQRS is from a conceptual/architectural standpoint and then explore what building blocks the Axon Framework provides that can help in building applications following the CQRS pattern.

The posts in this series include:

1. Exploring CQRS with Axon Framework: The Command, Command Bus and Command Handling Components
2. Exploring CQRS with Axon Framework: Overview of Some DDD concepts: Entity.
3. Exploring CQRS with Axon Framework: Building the Entity, Aggregate, Aggregate Root and Repository components
4. Exploring CQRS with Axon Framework: Introducing Domain Events and Event Handling.
5. Exploring CQRS with Axon Framework: Applying Event Sourcing.
6. Exploring CQRS with Axon Framework: Overview of the Testing infrastructure.
7. Exploring CQRS with Axon Framework: Closing thoughts.

Exploring Architectures

I would be spending some time in the next couple of days/weeks/months, exploring software architectures.

Software Architecture is obviously a very broad subject to contemplate. It could also be an ambiguous one. So I am going to exploit this ambiguity and broadness and limit my exploration only to activities which piques my interest (:p) meaning what my exploration will be mostly concerned with the development/deploying side of things (nothing on analysis, requirement engineering etc)

Why do this? Two main personal motivation.

There are a lot of buzz words and terminologies, and acronyms and what have you swirling around the activity of putting software together. From DDD to Layered Architecture, to Microservice architecture, to Command Query Responsibility Segregation, to Message Driven Architecture, to Reactive systems, to...you get the point? And obviously there are overlaps in the concepts these words represents: therein lay the first motivation: To cut through all these ideas and get to the core of the know-how they represents when it comes to putting Software together.

Then there are the slew of libraries and frameworks that are supposed to help build software following these aforementioned ideas: From Akka, to AxonFramework, to RxJava, to Reactor, to Vertx: list is almost endless. (As you might have guessed my exploring of the topic will be heavily influenced by the tools available in the Java/JVM ecosystem)

Second motivation is then a logical follow up off the first one: applicability. Make sense of the plenitude of tools out there. Know when their usage is most appropriate and how they help in applying the various ideas around putting software systems together.

I am definitely curious to see the ideas and tools (libraries/frameworks) these exploration would lead me in contact/familiarity with...posts that falls into this category will be aptly tagged “Software Architecture”.

Krwkrw 0.1.3 Released

Just pushed the latest release (0.1.3) of Krwkrw to Maven central.

Krwkrw is a web scraper. You can read how it came into being here

A quick run down of the changes in 0.1.3.

1. Ability to express URL's to be included/excluded using Regex pattern. For example:
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.match("(\\S+)(/projects/)(\\S+)")
   

   makes sure that only contents in the /projects/ path would be processed while
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.skip("(\\S+)(/projects/)(\\S+)")
   

   will fetch and process all the contents except, the ones in the /projects/ path
   
2. Ability to have random delays in between requests.
   Before now it was only possible to set the seconds to wait between requests. For example:
   

   Krwkrw crawler = new Krwkrw(action);
   crawler.setDelay(5) // waits 5 seconds between requests
   

   With the 0.1.3 release, it is possible to have random delay; that is, the requests will be delayed by number of seconds picked randomly from a lower and upper bound, for example:
   

   Krwkrw crawler = new Krwkrw(action);
   // waiting seconds will be any number between 5 and 20
   crawler.setDelay(5, 20) 
   

3. Change in API. doKrawl method replaced with crawl
   
4. Fix issue where it was possible for the crawler to crawl pages outside the origin url
   
5. Some minor improvements here and there...
   

If using Maven as your build tool, you can add it to your project via:

<dependency>
<groupid>com.blogspot.geekabyte.krwkrw</groupid>
<artifactid>krwler</artifactid>
<version>0.1.3</version>
</dependency>

If using Gradle, then:

dependencies {
compile "com.blogspot.geekabyte.krwkrw:krwler:0.1.3}"
}

The Javadoc can be accessible online here.

You can also check out Krwkrw on Github

What Does Changing Someone Else's Code Have In Common With Defusing A Bomb?

A while back, the above picture bobbled up my twitter stream...it was a morning of a weekday if I remember correctly...and as I was about to bop my head in agreement and push the retweet button: a gesture to show the picture also holds for me...It slowly struck me: that was not the case... this does not hold true for me...maybe it did before, but not anymore.

See, I understood the sentiments expressed in the picture so perfectly well. Either due to building on a codebase written by someone else (aka a former employee), or working on the same codebase with other developers. That apprehension of approaching someone else's code. That feeling of things blowing up, in unpredictable and unexpectable ways was just too familiar.