An idle thought

Posted by Jeremy Miller on August 31, 2006

I've had a couple conversations recently about Eric Evan's Domain Driven Design book.  I like the book, I like quite a bit of the DDD approach, I think it's an important book, and I'd recommend giving it a read.  That being said, we came to the conclusion at AgileATX lunch today that the DDD book might have supplanted the "Gang of Four" book as the leading cause of overdesign (except for SOA of course).  

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://weblogs.asp.net/pgielens Paul Gielens

    Have a background in mechanical engineering as well and ended up in software engineering for the exact same reason!

    Of course I disagree on the argument that the GoF nor Evan’s book is the leading cause of over-design. Over-design has nothing to do with books, actually it’s everywhere in our normal life… think about it.

  • jmiller

    Chad,

    Be careful what you wish for. I’m a developer because my original career in Mechanical Engineering was nearly devoid of creative thought — because everything had been discovered.

    If the best way to do everything in software development had already been discovered, software development wouldn’t be as much fun. Software development is still a new field.

    As far as overusing DDD & GoF & PEAA for that matter, it’s just a matter of getting higher up Bloom’s Taxonomy and being able to make better judgements on the applicability of techniques instead of just following along with someone else’s recipe.

    Thanks for the comments.

  • http://www.hdri.net Chad Myers

    “I’m embarassing” should be “It’s embarassing”

    But truth be told, I’m one of those guys who also can’t seem to find a sure-fire, tried and true, works all time regardless of what language/framework you’re using, way of accessing data from a database, so I guess I AM embarassing, as well as embarassed.

  • http://www.hdri.net Chad Myers

    Jeremey: It seems your comment goes a little deeper than just DDD. The problems of overuse of GoF and DDD seem to be that the software development world is yearning for a standard of some sort. We’ve been doing database-driven apps for many, many years and yet still no one has figured out how to do it well, testable, reliable, maintainable, etc. We’re STILL coming up with new ways of organizing software to work around databases. Still! It’s ridiculous. In the standard engineering world (mechanical, architectural, civil, etc) there are pretty standard ways of solving common problems. You need to fasten two steel beams together? Ok, tell me a.) How much weight they support, b.) what the shear force is, and a few other variables and I’ll look in the ASTM book and tell you what type of fastener to use.

    Ask 3 programmers what the best way to query data from 6 tables in a relational database and you’ll get blank stares for about 30 seconds, and then it’ll descend into chaos as the arguing starts.

    I’m embarassing, really. I’m embarassed to be a software developer sometimes and to call myself an ‘engineer’.

    It is my sincere hope that things like GoF and DDD help to raise the understanding an awareness of the art and practice of software development.

    You scoff (as do many of us) at the overuse of DDD because the people are using it as a new type of hammer to pound the same old nails without really understanding why they’re pounding nails in the first place.

    Well, ask me why the ASTM listed that particular type of fastener for those criteria and I couldn’t tell you. It’s not important because that fact has been established and tested and is tried and true for many years. I think we, as software artists and quasi-engineers need to get to the point where there are obvious, easily-obtainable and implemented solutions for standard problems and we don’t have to necessarily know or care why. DDD isn’t the silver bullet, but it’s one tiny step towards a standard way of dealing with a common, ubiquitous problem.

  • http://www.aspnetresources.com Milan Negovan

    It seems to me Jimmy tried to consolidate both doctrines (patterns/ refactoring/TDD, and DDD) in his book which worked out Ok. I think the GoF and DDD books will go hand-in-hand for some time.

  • http://www.stockham.co.uk Geoff Stockham

    I subscribe to the DDD mailing list, and I do find that there seem to be endless discussions on the best way to implement repositories and aggregates etc. I found the most value from the DDD book (and Jimmy Nilsson’s book) in the fact that it stopped me thinking about the infrastructure and made me concentrate on the domain. I now design from the middle outwards, rather than from the database upwards, and leave the infrastructure to tools like NHibernate and IoC containers

  • http://geekswithblogs.net/opiesblog Mike

    That’s interesting. Since I have been applying DDD concepts I have found myself eliminating wasteful design. I think that trying to build solely with DDD as a goal and without using the pragmatism of TDD practices leads to that kind of design bulge, tho. I think of DDD as a conceptual guide while I look to TDD as the way to realize the goals.