In response to someone’s comment of:

“writing all of these message objects takes a lot of time”

We have come to a very very very important question. What is the cost of Command Query Separation and Messaging in general in comparison to say a more traditional architecture?

I would like to look at this from two perspectives. The first perspective is that of the actual cost of using the types of methodologies I bring up. In other words what physical overhead can we see as a result of making the choice?

The first cost that people cite to me is that you have to create messages. There are generally more messages than there would be say DTOs because messages represent behaviors that are happening and carry the context of the operation to the server. Generally speaking you can have multiple behaviors for each piece of changed data so you will end up with more messages than simple DTOs.

So admitting that it requires us more time to type messages let’s make an attempt to quantify that time. Creating a message does not really take that long (especially if you use resharper). But if you are in a situation where the optimizing the typing of a message (generally around 1 minute) becomes an important optimization to you in terms of increasing your productivity I either would suggest you rethink using a domain layer as a whole or that you take advantage of code generation as you are likely in a fairly simplistic CRUD scenario.

The next cost is the actual creation of a “Read Layer” to perform querying. To remove any overhead of synchronizing models let’s for a moment forget about having a separate database to support the reads and assume that the queries are hitting say views on the normalized database that our domain writes to. In this case there is actually no overhead, it is simply a matter of where we are placing the code. Is the code in a repository or is it in a reading provider in another model?


I believe that this shows there to be a rather negligible cost associated with the use of such a model. There is however a small cost, this cost however I believe only exists when one looks at the system in isolation.

Systems in the real world very rarely run in isolation. It is far more common to see a mesh of system interactions. The point of sales context talks to the accounting context and to the warehousing context. The warehousing context talks to the inventory context and to the accounting context. The accounting context talks to the warehousing context, the inventory context…. You get the point.

The unfortunate reality is that it is quite common that you spend more money making everything talk together than building the things in the first place. One benefit that has not really been discussed of having a message based system is in terms of integration. It is far easier to integrate such a system into system of systems because everything that is happening within it is already available! We also tends towards a “subscription/denormalize” method for integration which leads us towards higher availability.

With a more traditional architecture we tends towards integration through databases. Integration through databases is a scary idea and should be avoided in all but the most naïve cases. If we try to make the traditional architecture not integrate through data we often end up spending more money that something like messaging from the beginning would have cost us in the first place!

When analyzing the costs of something make sure that you are looking at a wide enough perspective in your organization. Sometimes things that seem locally inexpensive are globally quite expensive (jeeze now I sound like Al Gore talking about global warming).