Are you doing DDD? or Do you think or hope you are doing DDD? or What is DDD?

Though it has died down a bit now there has recently been a fair amount of talk about dogmatism and Agile. Though I did not see anyone mention the irony of dogmatic agilists, it is an amusing concept. Anyway the only way I can envision considering yourself agile but being dogmatic is to not really understand what Agile is about. Well I have seen a similar phenomena with DDD(Domain Driven Design). It used to be most people who understood the words Domain Driven Design would respond to the topic with “yeah, I need to read that book”. Now, in my small world, many people say “yeah, we do that here”, or “we strive for ubiquitous language”. However, I have actually never spoken with anyone on a project with me who has read the book when the topic first comes up, and I am only aware of one colleague who has read it after we began discussing it (good on ya mate).

I have heard it said that the book is long and difficult (i.e. boring). Personally, I find Eric’s DDD book(http://domaindrivendesign.org/books/) kind of like the Lord of the Rings of software books, in terms of readability. I have read it 2 ½ times since it came out 4 years ago, versus 10-15 times for LotR since I was 12. I find it compelling and full of examples that I can translate into real world situations I have come across, that part is not similar to LotR.

In many projects I have been involved with, I have seen some level of recognition of the benefits to be had from DDD, and a desire to do DDD. But these same projects happily trod over the fundamental idea of ubiquitous language. In speech we try to use the same words, but in code divergence from the language is immediate and continues. The nouns may remain but the verbs and constraints get removed from the domain. In addition new nouns and verbs crop up in the domain code that are not translatable to the business domain or in violation of the business domain. Examples would include code with setters for Database Ids on domain objects or account objects that have setters on the account owner, when the business would not allow an account to change owners. These are examples of letting your domain do things that the business does not do, or extra things that have nothing to do with the business. On the other hand many other “domain” objects have no behavior, maybe the occasional validation method, or an equals override, but absolutely lacking in many fundamental domain concepts. If you have to give your domain object to a ValidationHelper to tell you if a “domain” object is in an appropriate state, yet the business rules of validation are dependent on the state of the domain object then your code does not use ubiquitous language. If you need to give an account to a PerformanceCalculator to tell you its performance over time, yet performance is a property of an account in the business domain, then your code does not use a ubiquitous language. If a “domain” object exposes information about a Database Id, or allows you to change (business) immutable properties because your persistence framework requires setters then your code does not use a ubiquitous language. Of course it may not be bad that your code deviates from ubiquitous language, but you should be aware of the fact and be able to justify it.

If you can’t justify it then you can fix it. My recommended way is to make sure you have read the book and start wrapping your behaviour in interfaces that are business readable(prerequisite is favoring a rich domain over an anaemic one). I would suggest that a good way to judge how ubiquitous your language is is to see how much sense your code makes to a business person. On that note, JBehave has recently been released, which looks to be an excellent tool to get the language of the business into your code. JBehave is about writing tests(behaviours, for BDDists) in the language of the business, but I believe it will lead the whole team to think more in the language of the business domain and that must lead to more domain code being readable in the business language. Of course you may decide that DDD is not for you and your team. But if you don’t read the book then you can’t really know. So my advice is read the book. Even if you don’t like the ideas it will give you a perspective on how developers can make the code easier to understand in the terms of the business.