Architecture on Software Engineering Thoughts

CQRS (and Event-Driven) Anti-Patterns

Fri, 21 Jul 2023 21:22:11 +0100

Over the years I have worked on a number of systems that would be classed as event-driven, and some of these have also implemented various parts of the CQRS pattern. More recently I’ve been working on systems and services that utilise the full gambit of CQRS and Event Sourcing. These have primarily been built using Axon Framework to provide the technical infrastructure.

While these approaches generally lead to really well structured systems, as with all software development, there are always some anti-patterns that tend to emerge. These make the solutions more difficult to understand, maintain and enhance.

The Essence of Axon Framework

Thu, 06 Jul 2023 17:39:58 +0100

Axon Framework provides an underlying technology platform to allow building of solutions that utilise the CQRS and Event Sourcing architectural patterns. It combines these with a message bus approach that allows for distribution, location transparency and service redundancy.

In this post, rather than describe Axon Framework in great detail, I just want to focus on the main essence of this framework. More details can be found in the resources section at the end of the post.

The Essence of Event Sourcing

Thu, 06 Jul 2023 15:29:25 +0100

Event Sourcing is a really interesting pattern in software engineering. It is an alternative approach to maintaining the state of a domain model and managing its persistence.

There’s a wealth of great material around this pattern and how to use it for building software. If you’d like more information then I’ve included a section at the end of this post with a list of useful resources.

In this post, rather than explain all the details of Event Sourcing, I want to just focus on what I think is the essence of this pattern. Armed with this information you can then go off and explore the subject in more detail.

The Essence of CQRS

Wed, 05 Jul 2023 17:07:43 +0100

I think one of the most interesting patterns in software engineering is Command Query Responsibility Segregation (CQRS). It is a super powerful way of thinking about certain problems and a way of building systems that solve these problems.

API Best Practices

Fri, 14 Apr 2023 21:32:35 +0000

Creating great APIs is hard. Getting the right level of abstraction and building something that is pleasant for clients to integrate with is a huge challenge. This post delves into this topic in more detail.

But first an anecdote…
Product Owner: “I need you to integrate with this third-party API as part of the current feature. It provides most of the functionality that we require in this area, and will avoid us having to write loads of it ourselves. Here’s the link to their documentation.”

The Problem With APIs

Fri, 14 Apr 2023 20:32:35 +0000

Creating great APIs is hard. Getting the right level of abstraction and building something that is pleasant for clients to integrate with is a huge challenge. This two part post delves into this topic in more detail.

But first an anecdote… (courtesy of Russ Miles)
Provider: “Ah, you’re missing the special field, BABEL-256. Without that field this behaves subtly differently…”

Consumer: “Wait, what??”

Provider: “Yeah, you can think of this service as a single front door where, past the door, there are a lot of different rooms, hallways, and functions available. ‘Service DoSummat’ is just the front door. The concoction of fields you pass are where all the magic happens. It’s Postel’s Law, we accept almost anything and that’s a good thing…”

Incremental Architecture

Sun, 29 Jan 2023 19:47:54 +0000

I have been having some interesting discussions with colleagues around evolving architecture and adding new requirements in an agile environment. The discussion raised some interesting points that I felt worthy of a blog post exploration.

Background

Imagine a simple system comprised of two main components:

Component A is the main component containing the key business logic. In order for it to do its job it needs to interact with component X. Mostly it needs to retrieve activity status from X, but it can also initiate a new activity from time to time.
Component X is a legacy system outside of our control. It has a number of peculiarities that make it challenging to integrate with. These include:
- Legacy format API payloads that aren’t mapped to a domain model
- Payloads that might not always be backwards compatible
- Release cadences that aren’t related to those of component A
- Periods of scheduled non-availability where some requests cannot be accepted and must be retried later
- Performance constraints requiring some throttling of requests
- High latency on some operations

Given the challenges of interfacing with component X, the team building the integration made a sensible decision and decided to keep all the complexity outside of the main component. Instead they added a new microservice, Component B. This component implements an adapter and anti-corruption layer that deals with, and abstracts away, all the eccentricities of X.