Sergey Shishkin

on agile software development

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.

Written by Sergey Shishkin

10.10.2008 at 23:15

3 Responses

Subscribe to comments with RSS.

  1. Hi Sergey,
     
    I think you have to elaborate on your statement "You probably will benefit from going data-centric way.".
    If I would have to implement "yet another web-shop/blog/you-name-it" I would start top-down and specs-first. Maybe I would use a front controller and the controller would talk to a service that acts as a facade, shielding the underlying model. All that would be driven by specs. The service would use objects from the business domain (shopping cart, cart item, blog post, author, whatever). Those objects would be relatively simple, maybe in v1 of the application some of them would be data-only without much behaviour. The last step would be to use a mapper to persist the objects to the database. Is that approach DDD? I think yes. Does it have a lot of data-centric classes in the beginning? Maybe yes.
    The biggest advantage I see with a clear DDD approach is that you can do it top-down specs-first. WatiN is nice for integration tests, but I don\’t want to drive my implementation by WatiN tests.
     
    So what do you mean exactly by "data-centric way" and why do you think you can implement much quicker than with a DDD approach?
     
    Cheers,
    Stefan

    Unknown

    11.10.2008 at 17:27

  2. […] Si en lugar de un producto estándar estamos en un proyecto de poco tiempo de duración, que no se espera que evolucione demasiado en el tiempo y cuya lógica de negocio no es completa, directamente no importa si hay experto en el dominio o no. No uses DDD, pero por muchas otras razones. […]


Comments are closed.

%d bloggers like this: