Does following the patterns make us domain-driven developers?

I have been reading a few interesting articles about agile methods these past few weeks. There have been various issues on it - too much to actually fit in a post. Fortunately , there is a nice article that summarizes all that have been going on. It will be best to read it because otherwise the rest of this post will not make much sense.

The question the article asks: by using agile practices, does it make the project an agile project?

InfoQ: Do Agile Practices Make it an Agile Project?:

"There's a down side, however: Agile also risks what one practitioner calls 'dying the death of a thousand copies,' if teams copy practices rather than growing them, implementing what worked elsewhere without understanding how to use continuous improvement to make the process suitable for their own unique context."

And I have the same thoughts about actually doing domain-driven design. There are a ton of patterns (or best practices) in the book. Some of them are really useful and some are less useful. It's extremely easy to get overwhelmed with all the patterns and start implementing them all over the place that the patterns themselves become a maintenance nightmare.

The same goes for a novice programmer who has just read Design Patterns. He or she is suddenly bestowed with the ability of x-ray vision: the ability to spot potential use for patterns everywhere!

Coding Horror: Head First Design Patterns:

"The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibility."

The main to realize with all this new faze thing is that there is no silver bullet. Plain and simple. Once you realize that, you know that at most all those snazzy new techniques can only help you so much. There is no panacea for everything.

So to answer the question: does following the patterns make us domain-driven developers? Blindly reading the patterns and applying them everywhere will not only lead to a team that is too conscious of the development process but also jeopardize future development because the project becomes a plethora of domain-driven patterns without anyone actually knowing the motivation behind those patterns.

Filter out the patterns; you do not need all of them. And incorporate only those that address an inherent problem in your current development process.

Update: Paul just told me that a lot of what I say on this blog sounds like what Fred Brooks says in The Mythical Man-Month. I read that book about 2 years ago so probably I can still remember the main points there. But since I do not have the book with me I cannot quote the revelant chapters. That said, I think 2 years is a sufficient time to go back and read the book for new insight. I will probably do that during Thanksgiving break.