The Data-Centric Modus Operandi: Part 2

An earlier post of mine, The Data-Centric Modus Operandi, has garnered a couple of good comments recently. I was in the process of responding to one of them when it occurred to me that (1) a response longer than the WordPress comment field probably didn't belong there and that (2) more readers might have the same question, and an answer in the comments wouldn't be very visible. So here it is, my feature-length response:

Frans Ott says:

Good piece of work Rick! Does this mean that practising the DDS-perspective, I will respect the business domain model more as it is? And that, as a consequence, less domain-burden will be drawn into the middleware?

This question is an important and perceptive one. My answer has a couple of parts.

First, DDS is not a panacea. Adopting DDS but using it in the same way you used your old messaging middleware can bring you incremental benefits in terms of performance, scalability, and flexibility. But it cannot by itself provide you transformative benefits in terms of time-to-market and long-term maintainability.

Those larger benefits accrue as you adopt data-centric architecture — that is, as you begin to model your business domain and tie your distributed applications to that model instead of to each other. You can start to do this with any middleware, not just with DDS, and doing so will allow you to more smoothly integrate capabilities over time without perturbing existing behavior. But when you use a technology like DDS, which unlike other middlewares provides functionality to directly support this type of architecture, you get an additional benefit: the middleware can start to automate things that you used to have to do yourself.

There's my second point: when you tell your infrastructure what you're trying to do, it can help you do it better. I used the word "model," which might sound frightening and esoteric. But everyone does this anyway! They just don't call it that. When people design a system in a message-centric way, they write long documents (aka "models") describing who has to send messages to whom, in what format, at what times. Then they email these documents to each other and implement the various components based on what the documents say. In the process, they write a lot of code to encode and decode data, validate it, monitor and respond to the system's status, manage application state, and so on. And once they've done all of this work, they plug their components in and find out whether the documents had any ambiguities in them and whether everyone has correctly implemented all of those infrastructure pieces I enumerated.

The truth is, from the point of view of the real business logic, "the middleware" isn't just a messaging or data-distribution component purchased off the shelf. It also includes all of the stuff your in-house infrastructure developers had to build on top of that to make the applications work right. A key innovation in DDS is the answer to this question: what if we took a lot of the ad hoc content out of all of those word-processing design documents and replaced it with a formal structure that the off-the-shelf middleware could understand? The answer is that the off-the-shelf component can start to do a lot of what the in-house "middleware-above-the-middleware" used to have to do — based on configuration rather than on custom code. The result is a more portable, interoperable system of higher quality and performance that was developed and integrated in less time. In other words: faster, cheaper, better.

You can use DDS as just a fast, interoperable way to send messages from here to there. Lots of people do. But DDS can do more than that if you're willing to design differently. DDS does for data in motion something like what an RDBMS does for data at rest. It can't make you create a good data design. But if you teach it what your design is, it can help you enforce that design, and it can reduce the amount of code you have to write in between your "middle"ware and your business logic.