Domain-Driven Design, the quest for software perfection

February 11, 2005 on 12:56 am | In General |

I’ve been reading “Domain-Driven Design”:http://domaindrivendesign.org, by Eric Evans, since August of last year. Reviews, both praises and rants, abound on the net — as demonstrated by the countless quotations in blogs alone — so I will not even attempt to do my own.

Why does it take so long to finish if it is so well-written? Simple. The book is a mine of information on domain modelling, basic concepts, methodologies, issues, etc. but contains very few code examples, which are the kind of materials that most programmers seek and rely on when studying technical publications. For a very long time, since I’ve started, in fact, I’ve been trying to make sure that I understood DDD concepts as the author meant it. I’ve formulated various interpretations, analysing every single word to try and find the exact meaning and how best to apply the knowledge. One might even say, it was a quest.

I think it has just ended, if indeed it was one. Today, I’ve scanned literally hundreds of blog entries, pages, and technical articles to try and map the book contents onto more or less compliant code scattered over the Net. At the end of it, I had to come to the same conclusion that I had known all along, but had refused to admit.

_There is no single way to apply Eric Evans’s teachings. In other words, the Holy Grail of DDD does not exist._

One is allowed to implement a design derived from a model as he sees fit. The details may vary, but the overall concepts must be respected in order to avoid an _anemic domain model_ — one that resembles a proper model, but only on the surface, as business logic is contained elsewhere.

While one achieves good models by having clear separations of entities, value objects, services, repositories, etc. one is also free to implement things, such as persistence, in any way they want, provided they adhere to good design patterns. One may also choose how the domain model is used: _what, why, how a model is called and by whom_. For example, I’ve spent countless hours trying to find the ultimate technique for saving entities, the recurring question being, should the entity trigger its own persistence or should a client of the model do that? The opinions posted in the blogosphere seem to contradict each other, but of course, each has its own merit. Still, I kept thinking that there could only be ONE TRUE WAY.

My enlightenment today after an n-th reading of the book is: it does not matter. The answer lies in the first and last chapters that suggests methodologies and identify the usage of the UBIQUITOUS language as the most important tool to succeed in DDD. Simply put, _standardisation_ is what matters. Make fundamental implementation decisions and stick with these through the development process. So, going back to my example, the case could be resolved by deciding on having client code ALWAYS triggering the save operation. Similarly, the answer to another question that has been floating around on the way to save aggregates will be used as the standard from now on.

What happened today is that I became aware of my mistake, the worst one that developers could possibly make, that is, being inflexible. Considering software development as science or engineering, it does not sound so strange. These fields provide mathematically proven solutions to problems, so why should programming be any different. But, it does. Programming is also a creative exercise.

This is a defining moment, I can finally appreciate the power of domain-driven design and I now understand the scarcity of examples in the book as the author does not wish to tie us to a single methodogy, but leaves enough room for developers to manoeuvre. The plan, now, is to make up my own examples and standardise the ways I implement my model.

Technorati Tags: Domain-Driven Design

Related Posts:

• Better software faster
• How to identify and fix an anemic domain model
• The ridicule of web applications
• Essential Software for Mac OS X