When To Use Domain-Driven Design?

Recently on the .NET user group in Cologne Sebastian Jancke made an introduction into Domain-Driven Design. One aspect of DDD remained untouched in the presentation — when should one actually go for DDD and when it is considered an overkill. So, I raised that question (quite provoking actually) and it quickly turned out into an interesting discussion.

My point in the discussion was that DDD comes with its price (relatively high, actually) and you should not use it until you see clear return on that investment. Some people in the audience, however, remained thinking that DDD is an always-win-way (if not even a "silver bullet"), arguing that other approaches cost no lesser.

Well let’s try to analyze what problems DDD is aimed to solve and thus where it is applicable.

What is DDD, by the  way?

The key concept of DDD is the Domain Model. Yet nothing new here, domain models in one or another form are present in every software. What actually DDD brings to the table, is the requirement to express the Domain Model in OO classes and keeping these classes clean of any infrastructure concerns (POCO/POJO). That’s it. And everything else told and written about DDD is just about how to actually make it happen!

Why is clean OO Domain Model so important? Each software development practice is aimed to effectively manage change. By keeping domain and infrastructure unaware of each other, DDD effectively allows independent change of each them. See the Onion Architecture for more on this topic.

Another reason for clean Domain Model is to split away essential and accidental complexity. While expressing the essence of the business in a pure Domain Model, DDD hides accidental complexity that infrastructure always brings.

So, when should I use DDD?

Now, when we understand reasoning behind DDD, we can adequate evaluate its usefulness for different sorts of projects. DDD makes sense for developing software of extremely high essential complexity (with a lot of correlated business rules). And/or software with clear future, where the Domain Model can outlast the infrastructure, or where the business requirements change fast. In other cases DDD may bring more accidental complexity than solve.

If you build yet another web-shop/blog/you-name-it (no complexity whatsoever, business doesn’t ever change), DDD is not for you. You probably will benefit from going data-centric way. Linq your data direct to the GUI. You will probably have to do much more WatiN-testing than unit testing, but the site will get up and running with this approach pretty quick compared to DDD.

When building the first version of a product, you want to get to market as soon as possible. Yet the future of the product is totally unclear. Designing the first version for change may not always be a clever decision — market may change faster and you’re out of it before you finish the product. In this case consider complexity of the business domain before going into DDD. If domain is not very complex, you won’t benefit from DDD here.

Once more, in my opinion, DDD makes most sense for building complex software where the need for change is determined. DDD, as any other approach, has its cost expressed in accidental complexity it brings, you should count on that.

Advertisement