Two recent blogs (well, within the last month or two anyway) about DDD have sparked this one. The first is from Jimmy Bogard, the second from Casey Charlton.
Apparently I need to mention this, but both of these guys are smart dudes. The fact that I’m reacting against what they are saying doesn’t mean I don’t think they are smart dudes. That should go without saying, but some people seem to think this is comment worthy.
Since Casey’s blog was first, let’s start with that, where he talks about ‘The Tao of Domain Driven Design.’ As I’ve mentioned before, I love it when white people use Eastern/Asian terminology to talk about software development (out of curiosity, is anyone aware that Motorola and Toyota both suck these days? And that The Art of War has nothing to do with .NET? Just curious.), so whenever someone references Taoism/Daoism (not to be confused with DAO, which comes from Java) when it comes to software development, I get the giggles. Doctor has prescribed something for it, so I should be okay.
Anyway, Casey is pointing out/lamenting is that DDD is not really (just) about the familiar software patterns (repositories, entities, services, etc.) that are a part of it, but is more about the experience of implementing the ideas popularized (not invented, in case anyone is confused) by Evans. In particular, the basic idea (massively paraphrased) is that developers and business users/customers (it depends on the environment if it is either/or or and) should work closely together in developing a common language (called the ‘Ubiquitous Language’) that is used throughout the design process by both the developers and the users, in order to more closely align the two sides throughout the development process. Although there is no explicit linkage with DDD and, say TDD/DDD/XP/Scrum/Whatever, there are some commonalities in play.
Where Casey goes wacko is with this:
“There is technically nothing new or revolutionary in DDD, there is only a guide to a better way of thinking.
While the Tao cannot be expressed, Taoism holds that it can be known, and its principles can be followed.”
Hold that thought.
Jimmy makes very similar points when attempting to answer the question “Where are the DDD sample applications?” His answer is that there aren’t any, because the question is misguided:
“A finished application does not capture the journey. It does not capture the conversation. It captures the final product of learning and application, but not the road to get there. “
Within the comments, we had a little bit of a back and forth (I didn’t want to keep harping there since it is his blog, but this is my blog and I can harp if I want to, harp if I want to) and Jimmy said this:
“I say it's tied to the journey simply because of experience of going through many different iterations over the model, the discovery process, and the refinement of the model. THAT'S the most valuable piece of DDD, IMO. It's how we went about arriving at the model, the questions we asked, the modeling and learning sessions we had.”
Now, I think that both Jimmy and Casey are bringing up a good point, that when practicing DDD, it is as much the practice (e.g. the development of the Ubiquitous Language) that matters than the software artifacts (e.g. the codebase).
BUT, having said that, I think they both get something important wrong.
For one thing, DDD, or the practice of it, is absolutely NOT inexpressible. Evans wrote a book on it. Some people make the mistake of treating his book as a religious document, but regardless of that, you can express/describe/whatever the process of implementing DDD. To suggest otherwise is to think that DDD is some ‘mystical’ thing, and the very fact that Evans, and others, have so described the process proves that wrong.
Moreover, the idea that with DDD, you have this need to go beyond the codebase and have whiteboard sessions, etc. that is different from other types of development is simply false. With just about any environment, including those using data-driven architectures, you have to go beyond the codebase and have whiteboard sessions, etc. to really understand what is going on. “Understanding the domain” is important whether you are doing DDD, TDD, or so-called ‘Cowboy coding’ (minor digression, but most of the best developers I have ever known, at some point, when really needed, did ‘Cowboy coding’).
To suggest that DDD requires an extra-super-special mystical experience is not only a false characterization of the truth, but also makes it that much harder to get a business to consider implementing it. And it absolutely is possible to use sample applications to get people on the right road to implementing DDD. Otherwise, DDD is a dead design methodology, because you will always have developers coming into a situation that weren’t a part of the previous ‘journey’, by definition. They will, of course, start out ‘behind the curve’ so to speak, but the very idea of an Ubiquitous Language is that you can get up to speed with it.
DDD is not a mystical journey, and it is not rocket science. It isn’t easy, sure, but it is still software development.