It is always nice to have a practical break-through in gaining a deeper understanding of a certain pattern. I experienced this a few days ago with the CQRS pattern.
What is CQRS?
For those who have not yet heared abaout CQRS start your reading with
this blog. I will try to summarize it in a few words: the acronym is for Command and Query Responsibility Segregation. On a method level it simply means to have methods that either return a value (Query) or that do something (Commands):
Instead of:
public double Add(double x, double y)
Write:
public void Add(double x, double y)
public double GetResult()
This "Method Level CQRS" is called CQS (Command Query Separation) and was devised by
Betrand Meyer.
CQRS takes this idea and leverages it to the application architecture level. It promotes the idea that commands and queries are two completely different things that need to be treated differently. A common argument for this is scaling: due to the fact that queries are far more frequent than commands, you should be able to let ten servers run queries while one server for executing commands will suffice.
I am not Google - what do I care?
Besides the fact that CQRS enables you to do other nice things like event sourcing, and that it fits nicely with Domain Driven Design you may ask yourself why you should care about scaling if your application will never reach such a massive scale.
Here comes the personal break-through I had: you should care, because commands and queries are simply different! Here is my example: Consider a service based environment. It was decided that every service operation will always deliver its result by means of an object called OperationResult<T>:
public class OperationResult<T>
{
public T Result { get; set; }
public Message Message { get; set; }
public bool Succeeded { get; set; }
}
The Message class simply holds some describing text, a message number and a list of Message objects.
Problems arised with the Succeeded-flag and how to construe it. I one thing we all agreed: if an exception occurs, the flag must be false. But what if a Method like "ChangeOrderState" does not succeed due to validation errors or any other business logic? Then the operation is failed as well. But what if you have a method like "GetCustomerById" - if there is no customer with a given id, the Result will be null. But this is a valid result. But isn't the method failed because it was the users intention to find something? But in the client we want to check succeeded and if it is false, we assume that something did not went well and we dont want to check for the Result to be null in this case.
The crux in the above example arises from the different nature of a method called "ChangeOrderState" and "GetCustomerById". The former is a command while the latter is a query. And besides technical failures, a query can not fail - but a command can. The way of interpreting the succeeded flag depends upon the kind of method called.
Commands and queries are different
I very much enjoyed having this insight, because it showed that CQS and CQRS are relevant to every developer, regardless of the size of your project. You should be aware of the fact that queries and commands are different and you should perhaps treat them differently.
For example in having a QueryResult<T> and an CommandResult<T>. Or, even better in the sense of CQRS, have a QueryResult<T> and a CommandResult, where the latter does not deliver a Result but only the Succeeded flag and a Message.
