>In the past all the projects I have been involved in has been developed using "data driven design" i.e. using a relational datamodel as the "blueprint" of the application domain.
But after reading Jimmy Nilsson's great book on DDD I decided to give it a shot.
Being a "database guy" I had a hard time not thinking in terms of "how would this look like in a relational database". (Perhaps lobotomy to remove old "database design" thinking should be a prerequisite before trying DDD) :) Well, after spending some time on DDD, I must say that I love it. DDD allows me to focus completly on discovering the modeled domain without beeing distracted with things like "would I use a mapping table here?", etc. In my previous project we used datasets as data carriers and that produced code like:
But now with my new shiny domain objects (yes I know that custom objects for datatransfer has been around for a long time but with DDD it's mandatory to use them) the code looks like:
A lot better if you ask me!
I agree with Udi Dahan when he states that DDD requires "a higher level of skill to employ"
But I think this "problem" will fade away as people gets used to "domain driven thinking" and the tools eg. O/R-mappers is getting better and better. The latter is exemplified with the upcoming release of ADO 3.0. Making O/R-mapping a native component of the .Net-framework will certainly give DDD a great boost.
DDD helps you build more stable, maintainable and testable applications! (I'm also a TDD fan of course...) I'm in! , send me the bill!