CQRS and the Axon Framework

19 October 2012, 8:05 am

At its heart CQRS (Command Query Response Segregation) is a simple design philosophy highly suited to certain types of applications such as those dealing with reasonable size datasets, or event driven user interfaces. The aim is to separate the infrastructure code from the application logic, and also the create/update/delete (command) operations from the read (query) operations.

This in practice means asynchronous command processing and optionally separate infrastructure for command and query operations. Increasingly web applications are reasonable large scale and perceived ‘transactional’ behavior often involves multiple processes and calls to web services. This adds uncertainty and indeterminate periods of execution time to the operation.

The increase in service orientation (SOA), or servitisation as it is sometimes called, is clearly important to modern applications and carefully designed service architecture helps to avoid a nest of web service calls which may never return. However CQRS introduces a more realistic model which enforces data updates to be asynchronous, and encourages separation between command and query data, a pattern which may already be familiar or have already emerged from complex application designs.

Axon Framework

The Axon Framework is a Java CQRS application framework which provides all the hooks for effective CQRS design. The framework should fit existing infrastructure technologies, such as Spring, JPA and JMS. Production applications using this framework are starting to appear and its popularity continues to grow. Though the Axon provides an easy way to structure an application, it is possible ‘roll your own’ framework, and many existing applications that use messaging technologies probably do. The advantage of Axon is that it has been carefully thought through by those used to CQRS design and helps to enforce a specific pattern for developers to follow.

The future of software design?

It is likely that we’ll be seeing more applications adopting a CQRS architecture in the coming years. Ultimately this may be of particular benefit to applications where data may be updated and viewed by multiple users and this relies on external services. We will probably start to see an increase in web sites and web apps which update when events are processed. With the advent of HTML5 features such as WebSockets this becomes even more seamless as the client’s web browser will no longer need to poll to pick up changes, rather they will be ‘pushed’ to the client. Though there are a lot of challenges with larger scale applications, hopefully carefully implemented emerging design patterns such as CQRS will make like easier.