One of the longest running institutions in the United States is the Post Office. In fact, the very concept of mail seems to go back a couple of thousand years (see Mail). The system is very simple. You just follow the following steps:
- Place the letter to be delivered into an envelope
- Record the destination, and optionally the source on said envelope
- Pay the postage fee which could be a stamp to be affixed to same envelope
- Place the envelope containing the letter, addressed to its destination, and paid for, in to the postal system
- Go do something else
It is so simple that children around the world do it all the time. However, is it efficient? In contemporary times many would say it has been replaced by email. Possibly true, but just in case lets look at the steps for email.
- Write an email using an email client
- Record the destination email address, and optionally the source email address
- Connect to the email server
- Send the email to the email server containing the message, destination address, and possibly some credentials to prove you are authorized to use the system
- Go do something else
OK. So far it sound pretty much the same. So why all this noise about mail and email? Because it demonstrates a concept that is critical to the design of large complex systems. It demonstrates separation of concerns. You do not care how the mail or email reach their destination, and in absolving you of how is what separation of concerns is all about. Would it be more efficient to hand deliver your mail to the person you intended? Possibly, if you had nothing else to do, were going that way anyway, knew exactly where the destination was, and did not mind spending all of the money it cost in transportation for you to get there. If the destination was next door, or very close by, it might be better, but in most real life situations, it would be a waste of your time and resources. So you give the task of how over to a specialist that is able to do it more efficiently and leverage economies of scale.
I know! I still have answered the question of why this lecture on mail. It is because of a blog post by Greg Young entitled Cost? Greg is responding to the comment “writing all of these message objects takes a lot of time”. Greg explains his reasoning to use messaging, but I wanted to add my own take on it.
My simple answer is that we use messaging because it is the specialist in moving data in large systems. It is the analogue of the postal system. In complex systems we need to leverage the available resources more intelligently, and be aware of the shared nature of those resources. Long gone are the days when an application owned the whole computer it ran on it. We must consider the large number of processes running on modern operating systems, the multiple cores available to service them, and the distributed nature of application state.
When I get asked if writing all those message object take a lot of time? My standard response is – as compared to what? This question is the classic case of tunnel vision as applied to software development. The message models something, possibly state, but more likely an action. That same model will need to exist in any design as it represents some desired functionality. When you create the message class, your are explicitly modeling that functionality. If you opt for a non-message model, you still need that function, it is just implicitly implemented. The catch, is that now your unit test (you do unit test – don’t you?) will be more difficult to write. It will have other ‘things’ polluting the test, preventing you from explicitly testing the functionality you tried to model.
Complex applications can only be effectively maintained when they are partitioned into smaller more management units. This is standard application design just as the contract implied by a function call. Both are needed to grow systems over time. Messages are contracts that allow applications to scale more efficiently. It is significantly more difficult to grow a system that implies the message rather explicitly defines it.
The fundamental issue is that complex applications are comprised of many smaller applications with contracts to control integration. Messages are contracts that serve this purpose. In much the same way the letter is a contract with the postal system.