In other words I would probably do it in a large scale project as well.

You can have a look at a demo and download the source here (feedback appreciated):
http://larsen.blogsite.org/blog/?page_id=162

Maybe you can’t see a productivity improvement in DDD because you already apply it? I agree with hernan above, who said that DDD is 90% common sense. Maybe you are alredy using the real important principles of DDD.

Another possibility is that you build lots of systems, but you didn’t have to maintain those systems in the long run. With a clear Domain Model, it is much easier to understand and apply change.

I’ve also worked on projects where domain driven design wasn’t used. Constraints were enforced haphazardly if at all. Code to handle special cases proliferated. The business logic was hard to understand or change. The applications produced an unending stream of production bugs which consumed increasing development resources as new feature development slowed to a crawl.

I don’t think domain driven design is really anything new, however. It’s basically just entity relationship modeling for object oriented programmers. It’s nevertheless useful since many programmers aren’t familiar with E-R modeling and don’t see it as applicable to what they do.

With that said, DDD is too abstract. In theory it seems like a good idea but the underlining technology must be concrete and not abstract. What you will lose is precision in the implementation and efficiency.

I became a fan of DDD when nice tools made it possible to build applications using unencumbered object-oriented code. Hibernate and Spring are good examples as they allow developers to write Plain Old Java code that doesn’t explicitly deal with persistence, transactions, or the assemblies your objects find themselves in from one application to the next.

This unencumbered domain model is usually where I start most of my projects and since it’s straight-up and simple code it’s easy to test and easy to refactor. I think of the domain model as the “demilitarized zone” of these applications. The rest seems to fall in place once you have a good domain model.

I’ve seen several projects succeed in the face of shifting requirements because they had a domain model–with a good domain model developers are generally not afraid or hesitant to change things as needed. Done properly, the fallout from such changes is mostly contained to the domain model. Furthermore, teams that embrace DDD put a high priority on having an accurate and up-to-date domain model and often seek out and welcome such changes since they help the fidelity of the domain model. That contrasts sharply with other projects I’ve worked on where developers were afraid or hesitant to make such changes.

DDD is 90% common sense and I think the DDD community is self-conscious of this fact. The most common answer folks receive on the DDD mailing list is “it depends” and it’s the correct answer in my opinion. Every domain is different, every application is different, every software development team is different. Focus on understanding those differences and building code that models your domain directly and you’re doing DDD.

That’s it in a nutshell.

.02
hernan

Fail blog post is fail.
Your writing is inaccessible to so many potential readers..