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).

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Cost?

  1. Tomas says:

    Hi Greg,

    I used 2 model approach in one smaller project in the past. It was an custom ASP .NET extension of
    MS CRM. There were 2 reasons to do model separation:
    1. Perfomance
    2. CRM has rich query object API but with lack of join functionality

    Even a small(not so complex) project, the 2 model approach was good decision.
    But I still have one question/problem. I create a hypothetical example:

    There’s a marketing department. There’s a campaign administrator, that creates a marketing list by running query against list of all leads.
    There’s also campaign supervisor, that runs query against all leads in marketing list to assign them to individual marketing employees.
    There’s number of leads, let say up to million. None of both – campaign admin and supervisor want to manually choose from a matched list of leads to perform their goal, they don’t want to see such list. They are interested only in how much items the query matched.
    They want to perform some update operations by executing a query. Domain model is too fat/slow do handle this effectivelly. But it’s also out of scoope of “read only” model.

    How would you solve this problem?

    Thank you for any suggestions/reply.

  2. fschwiet says:

    Martin Fowler’s “Patterns of Enterprise Application Architecture” has a “canonical message” design pattern which is justified by the same argument you’re making here. It sounds like a book you might like.

  3. Adam D says:

    one more thing.. In the pub/sub type of system of systems that you tend to move toward as the software tends to grow, you now need larger messages to keep the loose coupling. How does that play into the quantification?

  4. Adam D says:

    Nice quantification. For the reporting side, you forgot to mention you can still leverage ORMs etc.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>