TAG | DDD
I am going to throw out a quick pattern name for this and call it Command and Query Responsibility Segregation or CQRS as we are in fact simply taking what would usually be one object and splitting its responsibilities into two objects.
At the time of writing CQRS does not have an official definition. It’s difficult to define CQRS with a definition that would be both simple and useful. To describe CQRS at an object level I’ve came up with a definition which is just a reworded sentence from Greg Young’s blog post:
Command Query Responsibility Segregation or CQRS is the creation of two objects where there was previously one. The separation occurs based upon whether the methods are a command or a query.
CQRS can also be defined at a higher level. Greg Young was kind to provide a definition:
Command Query Responsibility Segregation or CQRS is the recognition that there are differing architectural properties when looking at the paths for reads and writes of a system. CQRS allows the specialization of the paths to better provide an optimal solution.
CQRS pattern is similar to CQS by Meyer but is also different. CQS separates command methods that change state from query methods that read state. CQRS goes further and separates the command methods that change state and query methods that read into two different objects.
Benefits of CQRS
- The most simple benefit of CQRS is that it simplifies read and write models by separating them. Write model no longer contains queries and developers can directly focus on domain model behaviours. What otherwise could have been a repository with hundreds of different read methods mixed with different lazy loading, pre-fetch and paging strategies can now be hidden away in a separate read model.
Another reason is Divergent Change. Divergent change occurs when one class is commonly changed in different ways for different reasons. You might be modifying queries more often than commands which might not only break your read queries but your commands as well. By having them separated you minimise the risks of both being broken.
- The single most important benefit of CQRS is that by separating read and write models you can make different choices on different models. For example you may optimize your write model for write performance and your read system for read performance.
- Another nice feature of CQRS is the available option to easily distribute work across separate teams. For example the read part of a web e-shop application can be outsourced to less expensive developers offshore.
- Event sourcing is a different pattern which shares a strong symbiotic relation with CQRS. Once your system reaches an architectural level where you may need multiple data models it might and probably will introduce synchronization issues. It is then impossible to say which model is incorrect. In an event centric system where commands are translated into events by the domain model these events can be used as the primary data model. This not only solves data synchronization issues, but also significantly improves testing by allowing to test for “what didn’t happen” and opens easy doors for integration with other systems since other systems can now listen to the events published by the domain model.
- Eventual Consistency. In very simple terms Eventual Consistency can be defined as simply just caching. In event centric systems it is possible to delay the handling of published domain model events and handle them in a different thread or a process. This will make write and read data models inconsistent but it might significantly improve the performance of your commands.
CQRS is a very interesting pattern. By some it may even be considered to be the silver bullet. It isn’t. Like all patterns CQRS has tradeoffs. It may be difficult to sell CQRS to management since it’s not a well known classic approach to software architecture. Less known tools, technologies. As an example in the PHP world there are currently no mature service buses such as NServiceBus in the .NET world. It is almost impossible or more often than not worth the Return of Investment to migrate legacy apps to CQRS.
Recently I wrote about what Domain Driven Design is which only scratches the surface of DDD. I’ve decided to put a list of DDD resources available. If you come by any other DDD resources online please post a comment with your link.
Books / Papers
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- DDD Pattern Summaries (Free)
- Domain Driven Design Quickly (Free E-book)
- Domain Driven Design Step by Step (Free E-book)
- Effective Aggregate Design by Vaughn Vernon
Presentations / Videos / Interviews
- Vaughn Vernon on RESTful SOA or Domain-Driven Design – A compromise?
- Greg Young on 5 Reasons Why DDD Projects Fail
- Eric Evans on the State of DDD
- Greg Young on State Transitions in Domain-Driven Design
- Eric Evans on Domain Driven Design
- Eric Evans on What he’s learned about DDD since the book
- Eric Evans on DDD Emerging Themes
- Eric Evans on Folding together DDD & Agile
- Eric Evans on Strategic Design
- Eric Evans on Putting The Model to Work
- Jimmy Nilsson on Is Domain-Driven Design More than Entities and Repositories?
- Dan North on BDD & DDD
Websites and Blogs
Domain Driven Design can be described as a philosophy based on domain modelling. More accurately it may be be described as a very large body of patterns and pattern language in its own right. The term Domain Driven Design or DDD was coined by Eric Evans the author of the book Domain-Driven Design: Tackling Complexity in the Heart of Software also known in the DDD community as the “blue book”.
Understanding the DDD philosophy
The Domain Driven Design philosophy states:
- Most software projects should focus on business domain
- Complex domain designs should be based on a model
To understand the meaning of these statements one has to understand the meaning of domain and model.
Domain is a sphere of knowledge, influence or activity. The subject area to which the user applies a program is the domain of the software. In other terms if you work for a bank then banking is your domain.
Model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. For example a map is a model designed to solve a specific problem. A treasure map shows how to find a treasure, a political map shows the borders of countries. A model is a simplification. It is an interpretation of reality that focuses on the problem at hand and ignores the extraneous detail.
Models are designed to be useful to solve domain specific problems. For example in the past the universe was viewed in a geocentric way where the universe revolves around Earth. Heliocentric model is another astronomical model in which the Earth and planets revolve around a stationary Sun at the centre of the universe. Even though geocentric model is not realistic it is a valid model in it’s own right designed to solve a problem – the human desire to be in the centre of everything. It’s not a useful model when it’s used to compare planet movements.
Domain Driven Design advocates designing software systems to reflect the domain model in a very literal way, so that the mapping is obvious, also revising the model continuously and modifying it to be implemented more naturally in software. To tie the implementation to a model well requires tools and languages that support a modelling paradigm, such as object-oriented programming.
A well mapped implementation of a model usually expresses an object model that incorporates both behaviour and data. A decomposed domain model consists of common building blocks: entities, aggregates, value objects, services and factories.
Essential Principles of DDD
The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together. Ubiquitous language is a language structured around the domain model and used by all team members to connect all activities of the team with the software. It’s a shared, versatile language between team members and domain experts. A well designed model speaks to the developers through the ubiquitous language. It’s important to understand that a change in the model is a change in the language and vice versa.
When multiple models are in play on a large project it’s beneficial to define bounded contexts where these models apply. A bounded context is a linguistic boundary marking the applicability of distinct models. Usually a subsystem or work owned by another team. For example in a typical e-shop web application a sales reporting application could be defined as a separate bounded context.
Every domain consists of subdomains. For example a very common subdomain is billing. Such a subdomain is usually not the driving part of the domain and therefore not as important. It is harsh reality that not all parts of the design are going to be equally refined therefore priorities must be set. DDD suggests distilling the core domain by distinguishing it from other generic subdomains and applying the top talent to work on it.
DDD helps projects to develop a strong internal language, define clear context boundaries, and focus on the core domain. Domain Driven Design brings structure and cohesion into domain modelling which are much appreciated features of any software project in existence. The blue book has been released six years ago and since then it influenced many developers. Yet I feel it hasn’t reached it’s momentum. One can only hope it will reach widespread adoption.
Update: I’ve added a list of available DDD resources such as papers and video presentations.
I went to see Udi Dahan speaking on Command and Query Responsibility Segregation. The open talk was organised by Skills Matter who support the Open Source community by organizing free events and courses.
Udi Dahan is a world renowned software architect and speaker. Udi is a specialist in SOA and distributed systems. It is a pleasure to listen to Udi speak because of his ability to present ideas clearly and keep others wanting to see what the next slide holds.
Command Query Responsibility Segregation or CQRS is software architecture pattern. The pattern is about separating (Segregating) the read side (Queries) and write side (Commands) of the system.
A simple example would be an application that does event reservations. All read commands would be executed against a reporting database which is stale and can be de-normalized. All calculations needed to display the data have been done before populating the reporting database. All write commands like making an actual reservation or adding a new event is executed against a Domain Model with it’s own database. Domain Model is never used to execute reporting queries. Reporting databases are generated from the write side database after all needed calculations have been performed.
This architectural pattern simplifies the Business Domain Model making it behavior only making it easier to maintain. Another strong advantage of CQRS is system performance. CQRS approach accepts that reporting data can be stale. This enables easier development of highly scalable distributed systems.
Finally came to my senses to update the blog’s appearance and add more readability. Hopefully new content will follow. As much as I enjoy writing every time it’s a struggle to start.
To not make this post a shallow rant if you are interested in domain driven design check out Greg Young. I believe he has some very interesting insights towards domain driven design. Honestly I think he’s a software prodigy. I especially enjoyed few of his talks: