Jeremy D. Miller -- The Shade Tree Developer

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.

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

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.

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.

"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.

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.