DDD is not all-or-nothing

The Domain-Driven Design book (or, the Blue Bible), is chock-full of patterns.  Software patterns, team patterns, integration patterns and so on.  As a consequence, many readers might assume that DDD requires these patterns, that you must apply these patterns, and not following these patterns means that you’re doing DDD.

But DDD is an architectural style, not a blueprint for building applications nor a pattern cookbook.  Because DDD is an architectural style, we can’t make any of the following assumptions when applying DDD:

  • Implementing certain patterns implies we’re applying DDD
  • Applying DDD means we implement certain patterns

One question Rob Conery asked me during a conversation on DDD was, “How do I recognize an application built with DDD?”  We’ve already noted that you can’t look towards a set of patterns, so how do we recognize one?  A DDD application is one whose design is driven by the domain, hence “Domain-Driven Design”.

If I look at a clean domain model, well-factored with explicit responsibilities, I as a lay person could make no judgment on whether the application followed DDD or not.  If however, I talked to the domain experts, learned about their domain, learned how the domain knowledge was distilled, I would then go back and look at the application to find if it models the domain.  If the development team calls a concept an “OrderForm” and the domain experts call the concept a “ShoppingCart”, then immediately we see an impedance mismatch.  The team is not sharing the same model language with the domain experts, losing the benefits of a Ubiquitous Language.  They are likely not following DDD.

Another tactic to recognizing DDD is have both the domain experts and team explain the domain.  Counting the number of clarifications and special cases, “well, except, but” and “we” versus “they” provides a good indication that the domain experts and team are not on the same page.

The patterns laid out in the DDD book are a guide to help achieve the true goal of DDD: a shared model expressed as software.  Concepts like Entities, Repositories and others are in place to reinforce the architectural style of DDD by defining explicit responsibilities of recurring patterns.  Like other pattern languages, the DDD book creates a common Ubiquitous Language for practitioners of DDD, both lowering the barrier to entry and creating a basis for comparing notes between disparate teams and developer communities.

DDD is certainly easier to implement with the patterns described in the DDD book, but they are not required.  We can use the Active Record pattern and follow DDD.  We can use the Entity Framework or LINQ to SQL and follow DDD.  We can use hand-rolled ADO.NET, constrained to a 5-year-old legacy application, and follow DDD.  We can eschew Services for eventing, and follow DDD.

DDD is an architectural style that encourages model-driven design and a domain-driven model.  Following this style is following DDD, and merely implementing patterns only indicates that we can implement patterns.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in DomainDrivenDesign. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • > We can use the Entity Framework … and follow DDD

    What was it like using the Entity Framework on a DDD project? Were you able to apply the patterns as well? Did the framework make it harder to model the domain?

  • I agree using the patterns isn’t enough, and that you don’t need to use all the patterns.
    Also I agree that if you have a domain model, and if you work with the domain expert, and if you have a UL then you are flying. However if you don’t attempt to use some of the other DDD patterns, and yet still call what you are doing DDD, then I think you’re asking for confusion.

    I make this point because semantic diffusion is a nasty aspect of IT, good ideas come out with good terminologies and they get redefined for a range of reasons. In my view is usually a negative thing. I’d rather say that “We have a domain model and a ubiquitous language and use active record” rather than saying that I’m using DDD whilst actually only maintaining the most essential essence.

    Doesn’t mean they are always the right patterns, or that they are a complete list though.

  • @Scott

    I have a follow-up to this one on picking the right DDD tools. My point is that you _can_ use other tools. You could still apply DDD principles building an MS Access application, if that’s the technology you needed to use.

  • Just coming back to this afterwards, when you say…

    “We can use the Active Record pattern and follow DDD. We can use the Entity Framework or LINQ to SQL and follow DDD. We can use hand-rolled ADO.NET, constrained to a 5-year-old legacy application, and follow DDD”

    In this list I wouldn’t disagree with these, but on top of that in real life would you use the term DDD if we did not apply any of the design patterns?

  • I’ve read a bit of the Blue Bible.

    The main thing I’m really curious about here is the gradations of DDD. How hard and far do you have to push to unify that language before you can call an app DDD?

    Using your previous example of asking questions of the developers and the domain experts, would you consider something 90% DDD if only a few things were not ubiquitous and inconsistent?

    I’ve always had a hard time not looking at DDD as an all or nothing equation, and every time I see that it’s not it only brings up more questions and the question of what makes up DDD.

  • @colin

    If I look at a Rails app, which uses Active Record, doesn’t use Repositories, but still uses Domain Model, then yes, I would say it uses DDD. The other patterns are there to make the model to code paradigm easy.

    I just don’t think DDD is a term reserved for a specific set of patterns.

  • Eric

    DDD – A religion or a cult?

  • Interesting, to me they may be doing MODEL-DRIVEN DESIGN and using a UBIQUITOUS LANGUAGE but I’d prefer to describe it as model-driven design because otherwise I think we obfuscate/weaken the term DDD which is understand by most people to be style of model-driven design where the model is expressed using a range of patterns.

    We might be in aggrement though because if its just that the architecture is not using repositories then absolutely that might still be DDD…I just wouldn’t call *any* model/UL driven effort DDD.

  • Jimmy,

    There are indeed implicit patterns that go along with DDD. DDD is a pattern of patterns. If you remove the patterns, there’s not much left but the ideology.

    I have built Rails apps and EF apps. I’ve applied the maturity that lives in me that has grown from DDD practice to those projects. I promise that my capabilities for applying DDD were drastically reduced by the technological constraints.

    DDD isn’t just patterns, and it isn’t just ideas. It’s both, and when you de-emphasize one aspect, the other aspect suffers commensurately. If all you’re left with is the modeling and analysis ideas form DDD, you’re left with the stuff predates DDD and that DDD imported. At that point, it’s not clear that what you’ve got left is DDD at all – at least not very meaningfully.

  • @colin

    That’s why I believe DDD is both model-driven design and domain-driven modeling. Just model-driven design isn’t enough, the model has to be created from the domain.

  • Yeah that’s true, I’m just saying its not enough as the patterns are heavily associated with and are part of DDD. To me you can do model-driven and domain-driven modelling but not be doing DDD, just like I can do resource oriented development but not be using REST.

  • Woah, just re-reading…did me an Scott just totally unequivocally agree. Rock on.