Mark Needham

Thoughts on Software Development

DDD: Only for complex projects?

with 8 comments

One of the things I find a bit confusing when it comes to Domain Driven Design is that some of the higher profile speakers/user group contributors on the subject have expressed the opinion that DDD is more suitable when we are dealing with complex projects.

I think this means complex in terms of the domain but I’ve certainly worked on some projects where we’ve been following certainly some of the ideas of DDD and have got some value out of doing so in domains which I wouldn’t say were particularly complex.

What is Domain Driven Design?

One of the quotes from Jimmy Nilsson’s QCon presentation was that ‘DDD is OO done well‘ and I think there are a lot of similarities between the ideas of OO and DDD – in fact I think DDD has ended up covering the ground that OO was initially intended to cover.

Having our code express the domain using its own language rather than the language of the technical solution seems like an approach that would be valuable in any type of project and my recent reading of Code Complete suggests that this is certainly an approach that was used before the term DDD was coined.

However, if we’re truly doing DDD then in theory we should be modeling our domain with the help of a subject matter/business expert but from the projects I’ve worked on we can very rarely get access to these people so the modeling becomes a best attempt based on the information we have rather than a collaborative effort.

I’m not sure whether it’s actually possible to get a truly ubiquitous language that’s used by everyone from the business through to the software team by taking this approach. We certainly have a language of sorts but maybe it’s not truly ubiquitous.

As Luis Abreu points out, I don’t think there is a precise definition of what DDD actually is but for me the essence of DDD is still the same as when I compared it with OO i.e. Domain Driven Design = Object Oriented Programming + Ubiquitous Language.

What that definition doesn’t cover is the organisational patterns we can use to allow our domain model to fit into and interact with other systems, and I think this is a part of DDD which I underestimated when I wrote my previous post.

It also doesn’t take into account the possibility of doing DDD in a non OO language – for example I’m sure it’s possible to follow a DDD approach when using a functional language.

The value in using a DDD approach

As I’ve written before, I think there is value in applying the patterns of DDD even if we aren’t using every single idea that comes from the book. The approach of using just the patterns has even been coined as DDD Lite.

DDD Lite sounds to me like a particular subset of DDD but I would be quite surprised to find a project which used every single idea from the book, so maybe every use of DDD is merely a subset of the whole idea.

I’m not sure which presenter it was, but at QCon London the idea that we can use DDD to drive out the simplicity of our domain was expressed.

I would agree with this and I also think the idea of creating a ubiquitous language is very useful when working in teams, even if the domain is not that complex, so that we can stop doing the costly translations between the different terminologies people may be using to refer to the same things in the domain.

The idea of striving to make concepts in our code explicit rather than implicit is another idea which I think works very well regardless of the complexity of the project. Being able to look at code and understand what is going on without having to know a whole lot of context is invaluable.

Finally the organisational patterns of DDD, as Dan North pointed out at QCon, are valuable even in a non DDD context. We may not always use the DDD terms for what we are doing but I’ve noticed that a lot of the ways we interact with other systems have a corresponding DDD pattern which will explain the benefits and drawbacks of that approach and where it will and won’t be appropriate.

In Summary

I know neither of the authors are writing off DDD for projects with less complex domains but I feel the value that the different ideas can give to most projects is sometimes not recognised.

What the book has done well is bring together some very useful ideas for allowing us to write business software and since this is what a lot of us are doing it’s definitely worth looking at where the ideas of DDD can be applied.

Be Sociable, Share!

Written by Mark Needham

April 6th, 2009 at 7:21 pm

  • Hi, good article. I agree with you that DDD concepts can definitely be used in smaller scale projects and I try to use some of the ‘patterns’ in these types of projects. Typically things like value object, specification, repository, entity aggregate are useful in most projects.
    The organisational patterns are great to be aware of but more costly in time and effort for most smaller projects and I guess thats the main point that most of those high profile speakers are making.

    The cost-to-benefit ratio is not great for simpler projects where it’s really ‘get some info, process it and persist it’. Thats why patterns like ‘Active Record’ and ‘Transactional Script’ are in widespread use (that and the fact that most developers regress to procedural code when confronted with tight deadlines 🙂

  • Pingback: DotNetShoutout()

  • Pingback: The Rationalist Manifesto » Blog Archive » DDD = ?()

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #323()

  • Neil

    Great article,

    I’d have to agree and have found at least trying to create a Ubiquitous Language really helpful for all sizes of project.

    Perhaps not a strict interpretation of UL but even getting team members to just use the same terminology when discussing aspects of a domain really helps me! – (as well as forcing people to really think about what they’re saying).

  • Good post. I’m speaking at DevLink conference in August on the topic, “Domain Driven Design for the Average Application” .. in other words, how to use DDD concepts when the application is not enterprise level nor extremely complex.

  • sn

    Dude, DDD makes things over complex, currently I am working on a DDD project, and I know how our architect has screwed up the code on the name of DDD.

  • Previously I don’t know about domain driven design. Now only I have got it but I am not clear. Great work. Thanks for sharing…