The Greate Domain Model Debated - Continued.

I recently got this excellent comment from Jeff Grigg on my domain model debate article. I started to reply with a comment, but the reply got to the point where it became a bit of a blog post in its own right, so I thought it worth giving it first class status. Jeff wrote this:

Interesting concept: I particularly like the concept of using numeric weights and rankings, rather than just claims of preference. But we need to realize that we can use numbers to express our level of subjective feelings, and that doing so doesn’t make the results objective. I notice that, according to your numbers, the top two recommended approaches are: (#1) Anemic Domain Model, and (#2) Rich Domain Model, with all others trailing behind these. The difference between the top two is about 10% of the difference between the top and bottom (best and worst) approaches. So I’d say that even you’re numbers aren’t a strong argument against using RDM; they only show a moderate advantage of ADM, while showing that RDM is still better than anything else (other than ADM). About 46% of the difference between ADM and RDM is that you feel that ADM is twice as “encapsulatable.” I think it would be helpful to have a better idea of what you mean by the values, like “encapsulatable.” When I consider how well a class encapsulates its fields, I use the information hiding principles, concluding that an ADM object that exposes all fields with getters and setters is not well encapsulated, while a RDM object that hides its fields and exposes only operations is very well encapsulated. For about 23% of the difference between ADM and RDM, you feel that ADM is nearly twice as maintainable. My experience has generally been the opposite: For example, when interpretation and enforcement of codes and states is distributed throughout all the procedural modules that use a record, rather than centralized and encapsulated in the class that represents that record, then ensuring that all actions conform to the rules and changing the rules can be difficult, costly and risky. (For completeness, the remaining differences are: technological intrusiveness (15%), complexity of programming model (11%), and ease of extensibility (5%).) One last thought about the numbers: I find it interesting that “naked objects” gets a much different and much worse score than either ADM or RDM; only three others scored worse. I find this interesting because the Naked Objects Framework, which you link to in your article (see [http://nakedobjects.org/](http://nakedobjects.org/) for more info) is based heavily on the assumption that you will build a Rich Domain Model: With Naked Objects, there are no additional layers of logic between the GUI and the domain model, so unless all operations the user is interested in are in the domain model, the user will not be able to invoke them. And unless the operations are directly on the relevant business domain classes, the system will probably be difficult and confusing to use. Overall, I found this article and in particular your approach interesting and informative. I like the ideas; I just don’t agree with the conclusions.

Thanks for the thoughtful reply!

I acknowledge that this article is primarily a numerical statement of my bias, and that some of the frameworks I compared I had a lot less experience with than ADM, which was already my preferred choice.

I didn’t want the model to be interpreted as objective truth, rather as a means for me to determine whether ADM really was the best choice for me (on the kinds of projects I’ve been working with). I thought it possible that I might have scored some other technique higher, and thus should abandon ADM as my preferred choice. I guess this was a long shot, but until I gave it sufficiently systematic thought I wasn’t going to be able to say with any confidence that I thought that ADM is what you ought to be using.

I also wanted to make it clear that (for any given designer) it is possible to express opinions in a way that (as you so clearly demonstrated) others can easily highlight deficiencies in. Blogging is such a linear medium that I would have had to write an endless succession of posts to cover the kind of material I did in those two images! I think that would have taxed even the most patient of my readers. Being able to clearly express my thoughts in terms of a numerical weight means that you can easily compare the performance or maintainability of two techniques and take issue with my assessment. If your arguments are persuasive, then I can at the very least update my spreadsheet. For example, I will revisit the Naked Objects framework, and give it another try, since it’s clear I didn’t get the whole picture when I first read about it. It’s possible that the framework has undergone a lot of refinement in the time since I read about it, and is now more worthy of attention than it was. I can’t think of a better way (short of blogging to excess on minutiae) to get that kind of broad picture of a person’s experiences with object modelling than for them to score a model like this.

Given a broadly agreed set of benchmarks, it might be possible to add a level of objectivity to the figures. It must be said that most of the papers I’ve ver read on the efficacy of certain software engineering practices were little more than folklore. That is especially true in the case of the maintainability of software systems. If a design doesn’t interfere with the efforts of the maintenance programmers assigned to it does that mean that (1) the design was good, (2) the maintainers were the original developers, (3) the maintainers were very experienced with such designs. It’s clear that most information we have about the efficacy of programming and design techniques is for the most part anecdotal (even when dressed up in academic guise) and is of little more worth than our own personal experience of working with the code of others. We could really benefit from a degree of objectivity in these issues - there are so many orthogonal criteria on which a design can be judged. the problem is that measuring how well a design performed on each criteria is largely a subjective measurement. How can we find a way to get objectivity out of a comparison of design methods. Those do a cook off, and then interview the developers afterwards studies are not very useful. And of course you can get the same developers to do the project again using different techniques - they’d find the project too easy the second time round because all the problems were familiar.

What I wanted was to create a simple way to help people to think for themselves about the domain model debate. I’ve recently been listening to a great podcast about the enlightenment by Thomas Lacqueur, and one particular idea stuck with me which I think pertains to the current issue. Kant said that the enlightenment movement was a maturing of the consciousness of the population. Maturity for him meant not looking to an authority figure for guidance, but instead working solutions out for yourself. In his case he was referring to religion, and statecraft, but I think the principle applies equally well now. We should seek ways to make our own minds up, or at least have a truly solid objectively measurable argument in favour of a design principle rather than just endorsement by famous designers. Just because XYZ designer disparages ADM, does that mean we should abandon it? Not necessarily, we should first look at his or her reasons and what kind of projects they were using it for.

It sometimes seems to me that opinioneers are what they are because we require it of them. They have to have an opinion, and as time goes by those opinions have to get more extreme to be heard above the background noise. That is not currently as true in the object oriented design community as it is in the arena of politics, but the more people blindly follow design guidance the more it will become so.

Follow the tradition of the enlightenment - make your own mind up, and feel free to use or expand on my spreadsheet to do so. And if you can’t see my spreadsheet properly, then blame wordpress for only putting out narrow stylesheets.