DDD Mysticism

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.

posted on Sunday, October 26, 2008 8:27 PM Print
# re: DDD Mysticism
10/27/2008 3:42 AM
I don't think I was saying that DDD was "an extra-super-special mystical experience" ... what I was trying to say is that DDD is a way of thinking, the technical aspects covered in the book are almost irrelevant, and therefore any sample application written with DDD would miss the whole point of DDD. Add a significant number of videos covering the exploration with the business, and add in the evolution of those ideas, and you might have something.

Evans' own example application shows this fairly well - the technical codebase could have been done any one of a hundred ways, and even with the explanations it has it is still a weak reference. The only reason it works at all as a sample applciation is that it covers a very well known and understood domain, the one Evans has repeatedly explained and explored over hundreds of talks, presentations, and a whole book.

Almost all requests for help or a "sample application" on the various mailing lists are concentrating on the technical patterns and problems - and often miss the more important point.

Anyway - good reading as always!

# re: DDD Mysticism
10/27/2008 5:58 PM
Well, developers are going to concentrate on technical patterns and problems because they are developers (and let's not overlook an obvious potential roadblock: Evans' book is long and hard to read, and even the shortened version is not light reading). I don't see how any development methodology that can't somehow accomodate this fact has any chance of being successful in the long run.

I've posted previously about why I think the Ubiquitous Language might be impossible to create.

Maybe someone should create a 'DDD lite' that simply expouses the technical patterns, and then the 12 people who are in the right place to do full blown DDD can do it. If you know what I mean.

When I read about DDD, I thought it had a lot of merit, but the more I hear from people about it, the less likely I think you can do it in a practical matter unless you are extremely smart and incredibly lucky.
# re: DDD Mysticism
10/27/2008 7:29 PM
Good software is Tao, but learning to write good software is Taoism. There are many things about writing good software (as compared with Yin and Yang) where one thing is in effect driven, or being driven, by another. Thus you have successful DDD implementations here, but unsucessful DDD implementations there, despite the fact that all the steps were followed to the letter and conditions appeared to be same as in the successful implementation; because of some other little thing, being slightly off, the whole of the parts were different and thus it was impossible to be successful at DDD from the start.
# re: DDD Mysticism
10/28/2008 3:42 PM
actually I would say "DDD lite" should probably exclude the technical stuff and stick to the design stuff... A lot more useful
# re: DDD Mysticism
10/28/2008 6:19 PM

How are you differentiating technical vs. design? That sounds backwards to me. Respository/value objects/services/blah aggregate blah root blah would at least give developers useful patterns

Post Comment

Title *
Name *
Comment *  
Please add 4 and 1 and type the answer here: