Mar
10
2010

CQRS & the architecture coming along

In my previous blog post I made a proposal in the footnotes to rename the architecture that often comes along with the pattern CQRS. I thought of a “Circular Architecture” to clearly contrast it with a “Layered Architecture”. After a brief discussion with Greg Young and Alistair Cockburn about this I decided to take this idea under the microscope. They both claimed that the “Hexagonal Architecture” describes this architecture sufficiently. That got me thinking, since I respect both their opinions very much. First some definitions.

Command-Query Responsibility Segragation(CQRS) – the design style (pattern) in which commands and queries are distinguished and segragated over two different interfaces. The term is also used for the application architecture that often comes with it, but as Greg Young writes himself in  the blog post “CQRS and Event Sourcing”, CQRS is in itself a relatively simple pattern and no architecture. It is an extension of a pattern previously articulated by Bertrand Meyer as “Command-Query Separation”

Figure 1: No pattern, and CQS CQRS side off.
Figure 1: No pattern, CQS and CQRS respectively.

In the figure above, we successively see 1) a reference situation, where an implementation implements an interface where commands and queries are not distinguished, 2) Command-Query Separation as a pattern, an interface which contains both commands and queries, and 3) Command-Query Responsibility Segragation, in which commands and queries are distributed over two different interfaces.

Event Sourcing – in essence this is the name used for the pattern that any change in the state of an application is defined by an event and that event objects are stored in order of action during the same period as the Application state is preserved. See also the Bliki on Event Sourcing.

Figure 2: Event Sourcing, and the use of events as application state by an Event Store
Figure 2: Event Sourcing, and the use of events as application state by an Event Store

This I combine with the use of this event stream as a leading carrier of the application state. It should be possible to get an application back to its last state by repeating the events after stop / start (in a sense ‘playing back’). This is the pattern that Greg Young suggested as part of an implementation supporting the CQRS pattern. It uses an event store, that cooperates with the Aggregate Roots in the domain to support these functionalities.

Hexagonal Architecture (also known as Ports and Adapters Architecture) – This describes an application architecture as a (domain) model that is unaware of its surroundings and is only ‘busy with itself’. All communications with the outside world is done through adapters, using a certain protocol as if a port is opened to the outside world. Within Sogyo we also know this as the satellite model or the sunflower model, but where the Hexagonal Architecture puts “Application” in the middle, in the satellite model we put explicitly the Domain Model in the middle. Here is an image I’ve taken from the description of Alistair Cockburn of this architecture.

Figure 3: Hexagonal Architecture as described by Alistair Cockburn
Figure 3: Hexagonal Architecture as described by Alistair Cockburn
Figure 4: Hexagonal Architecture in detail, with a common structure
Figure 4: Hexagonal Architecture in detail, with a common structure

Characteristic elements of this architecture are that the ‘Application’ knows nothing of the world outside and the adapters perform the translation back-and-forth with the outside world. Important detail as you can see in the picture above, is that the database that is used for persistence falls outside of the application boundaries. In that sense it is different from the Layered Architecture, where all elements in a standard application are placed on top of each other, beginning with the database. We also see a separation between a user-side API and a data-side API, which has some resemblance to the separation between commands and events like those found around the domain model in case of event sourcing. However, queries go to the ‘application’.

The architecture often used with and assumed to be CQRS
The patterns of CQRS and Event Sourcing, combined with the use of a database that contains a data model focused on querying is now frequently described as an application architecture. Each of the elements in it is not new, but as a whole it is an alternative to the layered architecture, where the domain model (or business layer) is used for querying. And it is a solution to the problems that come from this querying. By keeping the querying fully to the read-side and by implementing it using a common database, it is possible to keep the domain model free of getters and setters (read is not necessary) and to use the event store as a leading storage of application state without performance problems. See below a picture with all the elements together.

Figure 5: Architecture which is now supposed to be the term used CQRS.
Figure 5: Architecture which is now commonly meant when the term CQRS is used.

In this architecture, we see the following:

– Separation of commands and queries over two interfaces (CQRS) 
– A domain model that only receives commands and sends (throws) events
– The storage of these events in sequence (Event Sourcing) 
– The storing of the state of the domain model based on these events, through the Event Store 
– Updating the Read Database by Event Handlers (EH) 
– The Task-Based User Interface fed with read queries on the database and sending commands

Together these elements constitute an alternative to the widely known Layered Architecture, whose basic form consists of the User Interface layer, Business Layer and Persistence. Within this architecture, both commands and queries flow through these three layers, so the business layer should be designed for both commands and queries, and there often a strong link between the domain model and the underlying data model of persistence, because these are used together all the time.

Can the architecture described above be called an Hexagonal Architecture?
I think this name would not grasp all the elements that we normally understand by it. The following items would be missing:

1. The HA does not describe a strict separation between commands and queries (but a start in that direction is given, granted) 
2. The HA does not describe the use of a database with an optimized read model for all queries 
3. The HA does not describe the use of an event store as a leading storage of application state

The missing elements and patterns could be seen as an addition to a Hexagonal architecture, they do not exclude one another. However, with the name Hexagonal Architecture I think only the area around the domain model is described. The ‘common CQRS architecture’ that we see above is not implied.

Conclusion
If the configuration of known elements can be called an architecture is not yet clear. However, it is able to stand in for a ‘layered architecture’. I think it is clear that the name “Hexagonal Architecture” does not fully cover the elements commonly found in a ‘CQRS architecture’. Simultaneously, this common CQRS architecture is often implied / meant when talking about CQRS. While CQRS in itself is a simpler pattern. I think these are confused, because there is no name for this architecture / configuration yet. Yet it is a useful alternative to the famous “Layered Architecture”. Can we therefore not call it ‘Circular Architecture’?

Figure 6: Circular Architecture: a clear name?
Figure 6: Circular Architecture?

 

Written by Rick | Tags: , , , |

4 Comments - Leave a comment »

  • Hi Rick,

    Thanks for this clear, well-written article!

    I’m jus wondering: what about locking and transactions in the circular architecture?

     Comment by Johan den Haan — Thursday, 11 March 2010 om 13:12
  • Thanks for the kind words! Hope it helps you in getting a clearer picture of everything involved in CQRS.

    Well, normally one would make one command = one transaction. And given the nature of the event store, for transactions, we could use optimistic locking. This will mean events that are generated on an aggregate root that has already been versioned up (by another command), will have to throw a concurrency exception. The domain might actually still make something of this, because the intent of the action is not lost.

    Greg suggests keeping the read database in the tranaction scope too, until this gets too bothersome. This will ensure consistency of the data you’re reading, of course. When this puts too much burden on the transactions (because of scaling up the number of db’s, for instance), you can always retract the transaction boundary to only include the event store. Your read db will then only be eventually consistent. Which in the majority of cases is enough.

     Comment by Rick — Thursday, 11 March 2010 om 13:43
  • […] Technology weblog IT -ESSENCE, CQRS & the architecture coming along by Rick van der […]

     Pingback by Command Query Responsibility Segregation | Dialogues Technology — Thursday, 13 January 2011 om 10:47
  • A bit late on the conversation, i’ve been working on the hexagonal architecture for a while now and as i see it, both CQRS and hexagonal do not exclude each other. They share some concept but the “read” part is different as in hexagonal it goes through the domain.

    Now i guess you could implement an hexagonal architecture while having the read part going around the model that would also fit the CQRS pattern.

    CQRS focus only on the separation of concern while exagonal focus on separation of concern but also on dependencies. In the later, you can completely replace any part outside the model without having any impact on the rest of the application.

    Anyway, having some sort of hybrid is not really a problem nor would it be to have a domain context for the read part inside the model … a bit more coding for not much but that would fit more the hexagonal architecture. But going around the model should be fine for the read part anyway since your database does communicate with the rest of the application through DTOs anyway.

     Comment by Alexandre — Wednesday, 8 June 2016 om 17:08

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud