Ingredients of a CQRS and Event Sourcing Application – A Simple Explanation

In this simple article, I would tell you all the components that make up a CQRS and Event Sourcing application. So if you know how all this files hook together, then you can build any application using the CQRS pattern.

Scenario: Order Placement Application

A user places an order(OrderCreatedCommand) via a UI application built in Angular(step by step here). An order is created with the quantity provided by the user and the item selected by the user. Once this order is created, a StockUpdated event is published which updates the product stock by depreciating it by the amount in the order. User is able to see list of orders and list of products on the UI as well.

Complete applications on Github

Angular UI app

Order processing app with Axon

All the Component

Now we would partition the component into three groups:

  1. API/Command Components
  2. Query Components
  3. Common Components
  4. Additional CQRS and Event Sourcing Resources

We also have a 4th group,  the Events components, which are spread through all the other components. Also note that there are some overlap between these components. Let’s now discuss these components;

1.  API/Command Components

These are components involved in the creation and handling of commands. I have used some codes to represent each component so that later, I would explain how they interact. The Aggregates are what is stored in the write store(remember in CQRS, there is both read store and write store). Commands are operations that need to be performed. In this case there are three commands for: adding a product, creating an order and updating the product stock. You can add more. There are also three events, command handler and event-sourcing handlers. Event-sourcing is simply a way to save and retrieve data from the write store.

Figure 1: API/Commands Components of CQRS and ES

Figure 1: API/Commands Components of CQRS and ES

2.  Query Components

These components are responsible for creation and response to queries. I have outlined three queries, but it can be more. The Read Model and Read Repositories is exactly the same as in normal ORM(Object Relational Mapping). The ProductView and OrderView are entities while the ProductRepository and OrderRepository are Jpa or Crud repository interface. Finally, for all the queries, there must be a query handler. Four of them are provides.

CQRS - Query Components

Figure 3 – Query Components of CQRS

3.  Common Components

The common components are involved in routing messages between various parts of the architecture. There are three gateways: the CommandGateway sends new commands into the command bus; the QueryGateway queries new queries into the query bus; the EventGateway publishes new events to the event bus. Also the buses are like channels to carry messages across:

  • Command Bus: a channel for commands moving from the gateway to the command handler
  • Event Bus: a channel to move events from the gateway to the event handler
  • Query Bus: a channel to move queries from the gateway to the query handler
Figure 3 - Common Components of CQRS

Figure 3 – Common Components of CQRS

I’ll recommend you follow my step by step to build the application so you can see how all these artefacts interact. Finally, I would like to differentiate between and EventHandler and an EventSourcingHandlers.

Both EventHandler and EventSourcingHandler responds to events. However, EventSourcingHandlers are concerned with reading and writing aggregates to the write store. Therefore, changes made to the state of an aggregate are persisted in the write store by the EventSourcingHandler. EventHandler on the other hands, can be made to perform a wide range of actions depending on the application requirements.

Additional CQRS and Event Sourcing Resources