There is a lot of interest in DDD recently, both in the book, and in the methodology, and in the buzzword.
As a book and methodology, DDD is an excellent way to approach complex software problems, and make them far more understandable and manageable. As a buzzword, DDD is in danger of being corrupted like many other good software practices.
To try and clear up some of the confusion around DDD, I am intending to start a series of short blog posts, covering aspects of DDD and trying to demystify it.
Domain Driven Design is actually pretty simple. It really isn’t that hard. That said, developers seem to have a hard time grasping it. I put this down to a great deal of inexperience, with many people who have just read the book in a cursory way saying “we are doing domain driven design” – these people then confuse the issue for others.
Very few people could claim to have done full-on-balls-to-the-wall DDD, due to the relative “newness” of the book, and the time the ideas it contain talk to peculate down. In addition I work in the .Net space, where DDD has taken longer to penetrate than the Java space where the book was formed. I have practiced DDD in some way on three live projects, to a lesser degree in some aspects, and closer to the “one true way” in others. So, like almost everyone doing DDD, I am no expert, beware anyone that claims they are.
That said, some of the “community” have done more with DDD than others. Their wisdom is well worth picking up along the way – with no specific favouritism or deliberate omission, I heartily recommend you read stuff by Jimmy Nilsson, Greg Young, Colin Jack, Udi Dahan and of course Eric Evans.
Some take the book, Domain-Driven Design: Tackling Complexity in the Heart of Software, to be “the one true bible”, but like everything in software, it is only a good starting point. That said, if you are stepping into DDD with more than a gentle dip in the water, this book will prove to be a very solid basis for going forward without drowning – I recommend it strongly.
For a quicker introduction, I recommend (and have done so in the past), downloading the InfoQ eBook Domain Driven Design Quickly. This distillation of Eric’s work provides a really strongly overview of what DDD is, and how it can help you.
When you remember that DDD is really just “OO software done right”, it becomes more obvious that strong OO experience will also stand you in good stead when approaching DDD. To do my part, I am intending to start a series of blog posts covering various aspects of DDD, to try and make DDD seem somewhat more approachable, and hopefully to try and show that DDD is a whole lot simpler than many make it appear.
02-09-2009 8:21 AM