June 2015

Volume 30 Number 6

Cutting Edge - CQRS for the Common Application

By Dino Esposito | June 2015

Domain-driven design (DDD) surfaced about a decade ago, inspiring software developers and architects. Beyond its concrete merits and faults, DDD incarnates an old dream to which anyone from the early days of the object-oriented paradigm can relate: the dream of building applications around a comprehensive object model to address all stakeholder requirements and concerns.

Over the past decade, many developers embarked in projects following DDD guidelines. Some projects have been successful, some not. The truth is an all-encompassing object model to cover any functional or nonfunctional aspect of a software system is a wonderful utopia. Especially in these crazy days of advanced UX, frequently changing business models and swinging requirements, a solid and stable object model is practically an illusion.

Recently, another method with another acronym started gaining momentum—Command and Query Responsibility Segregation (CQRS). CQRS isn’t the latest cool toy of software pundits. It’s not even as complex as most available examples imply. Simply stated, CQRS is a concrete implementation pattern that’s probably most appropriate for nearly any type of software application, regardless of the expected lifespan and complexity.

There’s not just one way of doing CQRS—there at least three different flavors. You could even nickname them after common marketing rules of hotel rooms and drinks: regular, premium and deluxe. Do a quick search for CQRS examples and articles and most of what you’ll find falls in the deluxe category. This is effectively too complex and overkill for most common applications.

CQRS is an approach to software development that pays off regardless of the project’s perceived complexity. At the end of the day, CQRS for the common application is simply a rework of the classic multi-layered architecture that leaves the door open for more impactful changes and evolution.

Commands and Queries

While developing the Eiffel programming language in the late 1980s, Bertrand Meyer came to the conclusion that software has commands that alter system state and queries that read system state. Any software statement should either be a command or a query—not a combination of the two. There’s a nicer way to express the same concept: Asking a question shouldn’t change the answer. CQRS is a more recent re-formulation of the same core principle: Commands and queries are distinct things and should be implemented separately.

The logical separation between commands and queries doesn’t show up very well if the two groups of actions are forced to use the same programming stack and the same model. This is especially true in complex business scenarios. A single model—whether an object model, functional model or anything else—can quickly become unmanageable. The model grows exponentially large and complex and absorbs time and budget, but it never works the way it should.

The separation pursued by CQRS is achieved by grouping query operations in one layer and commands in another layer. Each layer has its own model of data, its own set of services and is built using its own combination of patterns and technologies. More important, the two layers may even be on two distinct tiers and be optimized separately without affecting each other. Figure 1lays the groundwork for the CQRS architecture.

Figure 1 A Canonical and Multi-­Layered CQRS Architecture

Simply recognizing that commands and queries are two different things has a deep impact on software architecture. For example, it suddenly becomes simpler to envision and code each domain layer. The domain layer in the command stack is only concerned with the data and business and security rules needed to conduct tasks. The domain layer in the query stack, on the other hand, may be as simple as a direct SQL query over an ADO.NET connection.

When you place security checks at the presentation gate, the query stack becomes a thin wrapper around Entity Framework or whatever you use to query data. Within each domain layer, you’re also free to shape data in close resemblance with the domain needs without duplicating or replicating data to accommodate variegated presentation and business needs.

When DDD first appeared, it was about tackling complexity in the heart of software development. Along the way, though, practitioners faced loads of complexity. Many thought it was simply part of the business domain. Instead, most of that complexity resulted from the Cartesian product of queries and commands. Separating commands from queries reduces complexity by an order of magnitude. In rough math terms, you can compare CQRS and a comprehensive domain model approach in terms of N+N versus NxN.

How Do You Start Doing CQRS?

You can turn a basic create, read, update, delete (CRUD) system into a CQRS-inspired system. Suppose you have a canonical ASP.NET MVC Web application that collects user data to display in various forms. This is what most applications do, and what any architect knows how to build quickly and effectively. You can rewrite this with CQRS in mind. You’ll be surprised to see the changes required are minimal, but the benefits you can get are potentially unlimited.

Your canonical system is organized in layers. You have application services invoked directly from controllers that orchestrate use cases. Application services (often referred to as worker services) live in the Web server side-by-side with controllers. With respect to Figure 1, application services form the application layer. The application layer is the platform from which you run commands and queries against the rest of the system. Applying CQRS means you’ll use two distinct middle tiers. One tier takes care of commands that alter the system state. The other retrieves the data. Figure 2 shows the architecture diagram on a sample ASP.NET MVC project.

Figure 2 The CQRS Architecture for an ASP.NET MVC Project

You create a couple of class library projects—query stack and command stack—and reference both from the main Web server project.

The Query Stack

The query stack class library is only concerned with data retrieval. It uses a data model that matches the data used in the presentation layer as closely as possible. You hardly need any business rules here as they typically apply to commands that alter the state.

The domain model pattern made popular by DDD is essentially a way to organize the domain logic. When you make queries from the front end, you’re only dealing with part of the application logic and use cases. The term business logic usually results from the union of application-specific logic with invariant domain logic. Once you know the persistence format and the presentation format, all you do is map data as you would in a plain-old ADO.NET/SQL query.

It’s useful to recall that any code you can invoke from the application layer represents the system’s business domain. Therefore, it’s the invariant API that expresses the system’s core logic. Ideally, you should ensure no inconsistent and incongruent operations are even possible through the exposed API. So to enforce the read-only nature of the query stack, add a wrapper class around the default Entity Framework context object to connect to the database, as shown in the following code:

public class Database : IDisposable
{
  private readonly QueryDbContext _context = new QueryDbContext();
  public IQueryable<Customer> Customers
  {
    get { return _context.Customers; }
  }
  public void Dispose()
  {
   _context.Dispose();
  }
}

The Matches class is implemented as a DbSet<T> collection in the base DbContext class. As such, it provides full access to the underlying database and you can use it to set up queries and update operations via LINQ to Entities.

The fundamental step toward setting up a query pipeline is permitting access to the database for queries only. This is the role of the wrapper class, where Matches is exposed as an IQueryable<T>. The application layer will use the Database wrapper class to implement queries aimed at bringing data up to the presentation:

var model = new RegisterViewModel();
using (var db = new Database())
{
  var list = (from m in db.Customers select m).ToList();
  model.ExistingCustomers = list;
}

There’s now a direct connection between the data source and presentation. You’re really just reading and formatting data for display purposes. You expect authorization to be enforced at the gate via logins and UI constraints. If not, though, you can add more layers along the way and enable data exchange via IQueryable collections of data. The data model is the same as the database and is 1-to-1 with persistence. This model is sometimes referred to as layered expression trees (LET).

There are a couple of things you should note at this point. First, you’re in the read pipeline where business rules typically don’t exist. All you may have here are authorization rules and filters. These are well-known at the application-layer level. You have no need to deal with data transfer objects along the way. You have one persistence model and actual data containers for the view. In the application service, you end up with the following pattern:

var model = SpecificUseCaseViewModel();
model.SomeCollection = new Database()
     .SomeQueryableCollection
     .Where(m => SomeCondition1)
     .Where(m => SomeCondition2)
     .Where(m => SomeCondition3)
     .Select(m => new SpecificUseCaseDto
       {
         // Fill up
       })
     .ToList();
return model;

All data transfer objects you spot in the code snippet are specific to the presentation use case you’re implementing. They’re just what the user wants to see in the Razor view you’re building and the classes are unavoidable. Also, you can replace all of the Where clauses with ad hoc IQueryable extension methods and turn the whole code into dialog written in domain-specific language.

The second thing to note about the query stack is related to persistence. In the simplest form of CQRS, the command and query stacks share the same database. This architecture makes CQRS similar to classic CRUD systems. This makes it easier to adopt when people are resistant to change. However, you can design the back end so the command and query stacks have their own databases optimized for their specific purposes. Synchronizing the two databases then becomes another issue.

The Command Stack

In CQRS, the command stack is only concerned with performing tasks that modify the application state. The application layer receives requests from the presentation and orchestrates execution by pushing commands to the pipeline. The expression “pushing commands to the pipeline” is the origin of the various flavors of CQRS.

In the simplest case, pushing a command consists of simply invoking a transaction script. That triggers a plain workflow that accomplishes all the steps required by the task. Pushing a command from the application layer can be as simple as the following code:

public void Register(RegisterInputModel input)
{
  // Push a command through the stack
  using (var db = new CommandDbContext())
  {
    var c = new Customer {
      FirstName = input.FirstName,
      LastName = input.LastName };
    db.Customers.Add(c);
    db.SaveChanges();
  }
}

If needed, you can yield control to the true domain layer with services and domain model where you implement full business logic. However, using CQRS doesn’t necessarily bind you to DDD and things such as aggregates, factories and value objects. You can have the benefits of command/query separation without the extra complexity of a domain model.

Beyond Regular CQRS

The power of CQRS lies in the fact that you can optimize command and query pipelines at will, without the risk that optimizing one might break the other. The most basic form of CQRS uses one, shared database and calls distinct libraries for reads and writes from the application layer.

More sophisticated forms may have multiple databases, polyglot persistence, data denormalization for query purposes, event sourcing and, more important, a more flexible way to hand commands to the back end. It’s more flexible because using a bus to send commands and publish events lets you define and modify any task as it happens, in a similar fashion to managing a flowchart. At the same time, you can scale virtually up where you need to be by adding power and features to the bus component.

Many developers praise CQRS, but tend to limit applicability to collaborative and high-scale applications. CQRS isn’t top-level architecture and is technology-agnostic. To a certain degree, CQRS is even agnostic of design patterns, but it’s a pattern itself. It’s simple and powerful and just right for common applications.

Dino Esposito is the co-author of “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) and “Programming ASP.NET MVC 5” (Microsoft Press, 2014). A technical evangelist for the Microsoft .NET Framework and Android platforms at JetBrains and a frequent speaker at industry events worldwide, Esposito shares his vision of software at software2cents.wordpress.com and on Twitter at twitter.com/despos.

Thanks to the following technical expert for reviewing this article: Jon Arne Saeteras