Command Query Separation (CQS)

Command Query Separation principle says that your operations should be either commands or queries but not both.

CQS was introduced by Bertnard Meyer back in 80s. Even though CQS was introduced for Object oriented programming, it can, in fact, be applied to functional, procedural or structured programming. CQS can be applied to any operations, not particularly to methods, since it is applicable to different paradigms.

Wikipedia defines the principle as follows:

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.
Wikipedia

You can also scale out Queries and Commands independently.

We define a Command as an operation that has a side effect. Command is everything that has an observable side effect.

Query on the other hand is an operation that returns data. I am not strictly talking about database; it can be an operation returning data from any data source or from the operation itself.

It is technically possible to write operations that have both side effects and returns data, nothing prevents you doing that in most languages, and therefore CQS is a principle tells you not to do so.

Commands are operations that mutate, change the observable state of the system.

Common characteristics of these methods are they all return void. Then why would you invoke these methods? Because you would expect side effect. If they have no side effect, why would you bother invoking them, right?

Queries on the other than do not modify observable state.

Common characteristics of these methods are they return something. If a method returns something, it must be a query. Query operations are idempotent. If you invoke an operation once or many times, it shouldn’t change the state of the system. Asking the question many times, should not change the answer. It is safe to invoke a query, once or many times.

So it is easy to detect which methods are query and which are commands.

On the other hand you can use queries within commands.

The whole point is that; Just by looking at the method signature, you should understand which methods are commands and which are queries, and thus which has side effect or not.

If you follow CQS across your code base, you will learn to trust your code base and it will be easy to reason about the code. It is also very easy to apply this principle.

Martin Fowler says that CQS is not a principle, it is instead a rather reasonable suggestion. Because it is such a simple concept, for example, you can have two types of classes in your app one for Commands and one for Queries.

Martin Fowler shows one example on the bliki with:

Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop.
Fowler

CQS becomes much more important when we talk about distributed systems and idempotency. The queries are naturally idempotent. The commands are not naturally idempotent.

Query are generally what we need to scale, in most systems you have more queries than commands.

While queries are easy to scale, commands are hard to scale. Because queries can be eventually consistent.

 

Code that sucks

When you encounter a code like following, what do you do?

We really have no way of knowing what this method does, what it returns and what kind of message it takes until we look at the source code.

Why does this method returns a string? what should I expect in the string?

It is not enough to say that this code sucks, we need to understand why this code sucks and how can we make it better. It is not a vague feeling that this code sucks, there should be a reason behind it. We should reason how and why it is problematic.

spagettCode like this decreases productivity. Code can deteriorate rather quickly and effects long term productivity as well as maintainability. We can suffer from the consequences. Within couple of weeks we can end up having spaghetti code. We should refrain from deteriorating the code.

Impact of code like this, or the other codes that suck, is huge on projects.Thus we end up reading code more than writing code. We need to figure out a way for writing more code, product features, instead of reading it. We need a better ratio of reading vs writing code. We have to create APIs that is understandable and readable.

Code comments: the good, the bad and the ugly

While learning programming languages there are sections about how one writes comments for classes, methods and other code blocks. Many times importance of code comments are dictated.

B3qIJLFCcAEJLWmWhile using frameworks, SDKs and clients, IDE’s intellisense renders the comments so that we can understand the method, parameters etc. These are the good part, you can learn what you using, invoking and how to do that.

How do you use code comments?

Code comments should tell the other developer the reason why, the implementation was done that way, other than that it shouldn’t document the obvious such as documenting  this method “adds an item to the collection” for an “add” method of a collection.

Since code comments are not testable. How can you test code comments? How can you trust the correctness? Code comments can lie to you. The comments may be correct, or incorrect, we can’t really know unless we visually (and tediously) inspect the code for accuracy.

Code comments can lead to duplication as well. Many times code comments are not maintained by developers due to several reasons like time, cost, laziness and other priorities. Maintaining comments can be seen as a cost, spending time to maintain code comments costs me in terms of not taking the opportunity to improve the code such that I wouldn’t need the comments in the first place.  The benefits of making the code more soluble, testable, and consequently more maintainable are much more valuable than having up-to-date comments.

So, if maintaining the code comments are costly, difficult and time consuming below are the alternatives:

  • Refactor code so that it is soluble
  • Refactor code so that it is testable
  • Use intention-revealing names for classes and members
  • Use intention-revealing names for tests

It boils down to how do you develop your software, where is your business logic, your domain model and architecture. These should read like a poem.

Business problem of your software

Based on software architectures, business logic or business problem, lies somewhere specific within the application, if done right. This can be on server side, client side, or bit of both, and sometimes within databases (stored procedures) .

537px-Overview_of_a_three-tier_application_vectorVersion.svg

Image from: Wikipedia

We have monolithic applications that tries to have the business logic usually within some services or controllers(if we are using MVC). We usually have Domain entities and View Models (DTO) that we send back and forth between layers. Domain entities or model in this case doesn’t contain any business logic, they are just data containers so that we can persist the data to data stores via some ORM.

Then there are client-server or smart client desktop apps, which have partial business logic on client and some business logic on the server side (services).

This approach is also called anemic model. You can find several discussions on whether anemic model is an anti-pattern or not. Even though anemic model is pretty old way of doing things, today it is still applied to many software projects because of its simplicity.

Today many applications lack necessary documentation of where the business problem or logic resides. Worst ones are those which the business problem are on the head of developers. That being said, you should have a concrete planning and strategy on documentation and architecture of your apps to have your business logic.

Keep in mind data storage, and technology is not your business problem.

Open source projects we are digging in 2016

Here is a list of projects we are using and really loving them.

  1. Sentry

sentry-iconI really love sentry. It has added so much value to our software development team. We have about 120 small and large scale projects running for our organization. While some of them are outsourced, some of them are being developed in house. With Sentry integration, now we know what is going on in the applications. Sentry provides real time crash and error reporting. It has support for all the technologies we use. After integrating some of our big projects, we have found out many errors that we weren’t aware of. It helps us resolve our problems and create better user experience for our clients. Sentry has on premise installation.

  1. Taiga

logo-colorTaiga helps us manage our projects with agile and simplicity in mind. The greatest part of Taiga is that it is very easy to use. We needed an easy way to define tasks, document via wiki and resolve any issues. I personally prefer Kanban. Moreover, we can invite clients to define tasks and issues in the system. It was also pretty straight forward to install and start using it on our servers. Check out taiga github page. Couple missing things are reporting and responsive view.

  1. Gitlab

gitlab-logo-squareWe have been using TFS for version control. This year we are moving to Gitlab. Gitlab has hooks and integrations to Taiga and sentry. Moreover, there are several integrations provided. You can have code reviews. You can download and set it up easily.

 

  1. Piwik

piwik-carre_0First time I met with Piwik was while I was working at Ebay/Paypal. Back then we were storing reports generated from our Hadoop cluster. Piwik provides analytics at scale on your infrastructure. Being open source, you can store and visualize any kind of data with it. Currently we are using it as analytics systems of our applications. You can see the demo and download it.

  1. Moodle

300px-Moodle-iconIt was 2008 when I stumbled upon moodle. It was the best elearning system back then, it is still one the greatest one. We have adopted moodle for our elearning platform and been using it for almost 2 years now without any problems.

 

6. Mattermost

9828093Familiar with Slack? Mattermost is an open source alternative that you can install on premise and increase collaboration between your teams. A modern approach to communication between teams and members. Pretty simple and easy to use. Mattermost has integration to Gitlab.

 

Moreover, while using open source NoSQL solutions like mongodb, couchbase and redis, we are also checking out influxdb and druid for time series analytics. Also, for our GIS system we are looking into cartodb.

On a different note, we are training some data for predictions with prediction.io.

What is your favorite open source project? Leave it in the comments.