Command vs Command

After an interesting meeting in new company I decided to make a quick review of Command concept from different point of views. First of all, there is the classic Command design pattern by Gang of Four. On the other hand, we have more and more popular subject of Command-Query Responsibility Segregation, which is inspired by good old Command-Query Separation (but not same thing, Wikipedia is wrong). When you design a system, you might need to make sure that you and your teammates are on the same page.

In this case, let’s make sure that we all know the difference between these two concepts of Command:

GoF Command Pattern

In this pattern, we have some abstraction of Command which represents a contract of unknown behavior. For example (in Java):

public interface Command
  void execute();

Any behavior that fits this interface can be represented as a class extending our interface.

public class RemoveAllExpiredProductsCommand implements Command
  public void execute()
    // logic, delegation, whatever works for you

We can now have many objects of type Command and queue them, or, for example, attach to different executors to make dynamic customizable UI. There are many other appliances of this pattern, but in order to make sense out of it, let’s sum up how it works:

  • Each command implements same interface with a simple method to fire
  • Each commands represents a behavior

Command in CQRS

In CQRS, a Command means something different. It’s mostly a simple value object representing data, not behavior. Example:

public class RemoveAllExpiredProductsCommand implements Serializable
  private Date expirationLimit;

  public RemoveAllExpiredProductsCommand(Date expirationLimit)
    this.expirationLimit = expirationLimit;

  public void getExpirationLimit()
    return new Date(expirationLimit.getTime()); // hello, shitty Java time API

Now our Command is just a sad kind of “struct“, so we could implement it much easier with, for example, Scala case class and get free getters, equals+hashCode and immutability (still, watch out for Date class). Let’s leave this subject for now. In order to execute a concrete behavior, we get such object and throw it into a generic listener, who is capable of finding an appropriate Command Handler. Such handler can then deal with logic or delegation:

public class RemoveAllExpiredProductsCommandHandler implements CommandHandler<RemoveAllExpiredProductsCommand>
 public void handle(RemoveAllExpiredProductsCommand command)
   // proper handling

So, to sum up:

  • Command is a dumb DTO-like structure representing execution request parameters
  • Command Handler is responsible for capturing our DTO and it represents the behavior

If you want to build your model using DDD and CQRS then you are looking for the DTO+Handler option. Here’s github link to a good example in Java. It clearly fits architectural ideas and well-known building blocks from this realm, where a Command encapsulating behavior (the GoF option) is a nice pattern but can be confusing inside a domain where normally the behavior is implemented within entities, services and other blocks designated for that purpose.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s