Domains in context

A few days ago I attended a two day overview of Domain Driven Design (DDD) presented by Aslam Khan. On the surface, DDD looks like the latest wave rolling in from the timeless ocean of IT fads. Dig a little deeper and you'll find that there is nothing new to DDD. It is not a new wave, and just maybe it won't go away. To be fair, there is definitely a new buzz in the air. DDD is whispered about in many corners, not all of them dark ones. There seems to be high hopes: SOA, web-services, behaviour driven design, test driven design, Agile, Scrum – all of these good things could benefit from DDD.

My interest in domains started long before I read the DDD book by Eric Evans. I have been the driver behind a few frameworks for domain driven development efforts, and with a team that contained a few good men (and one or two woman), I have tasted the sweet successes this approach can bring. The road was not paved in gold, often I felt like a lone ranger taking it upon myself to lay bare the obvious traps of data-bound controls and other evils. Lucky for me (and for Tonto) the world is changing.

Reading the Evans book was a real pleasure. Not only did I find that it agrees with the undeniable truth, but it also had wrapped in it a few patterns I really needed. We grabbed from it some pieces to create yet another framework. Of course this one (like each of its predecessors) promised to be the best framework of all. And the promise was delivered - the time was right, the problem needed it, and the book came in very handy.

It is fair to say the patterns in Evan's book are less vague than the Gang of Four. The book may also present the uninitiated with too many options. Place your focus on putting together the machinery that allows the development teams to roll out those precious domain classes. Keep in mind these classes must be loosely coupled and highly cohesive modules. But do not forget: on top of these classes some key user interfaces are needed; and on their sides high performance processes hammer them into shape. Do not even get me started on the mapping to the relational databases at the bottom of your architecture. Quite an interesting design challenge I assure you.

Maybe now you can understand why I was wondering how Aslam is going to chunk in years of experience and lots of ideas into a mere two day workshop. Selling DDD is difficult and implementing it for the first time is harder. Pleasant was my surprise when I noticed that he will attempt neither. Take the view that DDD is sold, and regard the implementation issues as infrastructural detail best left to others. Do this and your frame of mind is where Aslam wants it to be.

"Ah, but what else is there?", you may ask. The answer is obvious – it is the thing that drew all of us domain driven junkies closer to the kindle when we started on our journey. It is the absolute belief that the domain model is the key asset amongst the components of the enterprise software. It is where the knowledge lies, where the growth and refactoring happens, and also where the fun never sets.

Aslam's two day take on DDD focussed on this most important of stuffs. It is all about how to get the right model. He pulls together current topics and discusses those patterns from leading DDD books that help you come up with a good domain model from the start. Have a look at this reference card if you are interested in more detail of what he covered.

Consider yourself reminded: without the right model, the benefits of DDD will always be out of your reach. Thank you Aslam!