Where are the DDD sample applications?

It’s a question I see quite a bit, on the ALT.NET mailing list, the DDD mailing list, and any other medium where DDD comes up.  For those trying DDD, this is a rather difficult question to answer.  Many have tried to create DDD how-to’s and samples, including Jimmy Nilsson in his book.  The problem with these examples are twofold:

  • They only show the code-level software patterns
  • DDD isn’t defined as a specific architecture or a specific set of software patterns

There are plenty of software patterns described in Evans’ book.  Entity, Aggregates, Value Object, Aggregate Root, Services, Repositories, Factories and so on.  But merely applying these patterns misses the point, it’s (sigh) cargo cult DDD.

DDD is first and foremost about a model expressed as software.  Businesses have processes and tasks they do, and DDD attempts to bridge the gap between developer and domain expert by applying patterns that help transfer a model of reality into code.  Techniques like Ubiquitous Language attempt to reduce the amount of translation between software model and conceptual model.  Building a robust Ubiquitous Language requires extensive conversations and learning on the part of the developer.

And therein lies the rub.  A finished application does not capture the journey.  It does not capture the conversation.  It captures the final product of learning and application, but not the road to get there.  It does not capture brainstorming or whiteboarding sessions.  It does not capture (well) major decisions and their effects on the model.  Without this journey, the value of the destination is severely diminished.

In Evans’ book, he goes into fairly deep discussion about the domain his examples use.  He also provides sample conversations, sample whiteboarding, and sample modeling sessions.  Some of these are reflections of real conversations and real events.  If you’re looking for a DDD example, it’s Evans’ DDD book.

However, if you’re looking for technical examples of the Repository pattern, ask for that instead.  If you Google “repository pattern” or look for NHibernate examples, you’ll find plenty of resources on how to apply the technical patterns.  Keep in mind that using the Repository pattern does not equate to practicing DDD.  And those who (at least believe) they understand what DDD is all about, a request for DDD examples really doesn’t make any sense.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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 Domain-Driven Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://devlicio.us/blogs/casey Casey

    Oddly, there is now an example app … though I agree with pretty much all you said …

    http://dddsample.sourceforge.net/

  • http://devlicio.us/blogs/tim_barcz/ Tim Barcz

    Jimmy,

    It’s not too hard to understand why people want to see examples. We were indoctrinated with examples. From what I understand you are correct in your statements (as I going through Evans’ book now).

    Somewhere along the way DDD somehow morphed in people’s minds into a technological solution rather than a solution to design problems. Heck it’s got “design” in it’s name. DDD isn’t about technology…that much I’ve gotten from the book.

    Preach it Jimmy!

  • http://tobin@tobinharris.com Tobin Harris

    “A finished application does not capture the journey. It does not capture the conversation. ”

    I think Evans said that the packages (namespaces) of a system should tell a story about the domain. E.g. – simplified example of one of my recent solution structures…

    WebSpider.Domain
    UrlSources
    Scheduling
    Crawling
    Indexing
    Storage
    WebSpider.Infrastructure
    DataAccess
    ContentManipulation

    I know it’s not quite the same as capturing the journey, but I’d be interested in seeing examples of how people have told their story through namespaces?

  • http://www.blogcoward.com jdn

    Are you saying anything more interesting than “You can’t teach experience”?

    It’s like saying you can’t produce TDD examples because they don’t capture the process of writing bad tests, refactoring them over time, etc. etc. etc.

    Which is true, but sort of irrelevant.

    I can’t live other people’s lives, but I can learn from their experiences through stories, novels, etc.

    Software isn’t really any different in that respect. DDD isn’t nuclear physics or mystical daoism. Evans was able to write his book, and other people could provide samples if they wanted to.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @jdn

    No, it’s more along the lines that it’s not a valid question, IMO. DDD is a design process, not a collection of patterns. The book is already an example of “how to do DDD”. If people have the misconception that DDD is a collection of patterns, it’s important to point that out.

    There’s nothing wrong with asking for examples of Entities, Repositories, etc. Just saying, make sure the right question is asked/answered.

  • http://www.blogcoward.com jdn

    Suppose you are a new developer coming into a company that has already successfully employed DDD (sure, it’s an ongoing process).

    What you seem to be saying is that the new developer can’t look at the code base and figure out the domain or really understand DDD because he wasn’t there when it was produced, wasn’t there for the ‘journey’.

    What is the *point* of having a ubiquitous language, if you can’t create intent-revealing code that a new developer could use as a healthy ‘leg-up’ to learn the domain? And if he can, then you can create a DDD sample.

    “A finished application does not capture the journey”

    So what? This isn’t pop psychology, it’s software development.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @jdn

    When we bring people on, the codebase is only one of the items we show. We also have whiteboarding explaining the model, presentations on the domain, flow diagrams explaining service interactions. It’s just hard to capture all of that in a Google Code project that anyone can download. Since software is a reflection of the model, it’s still important to understand what the original conceptual model is.

  • http://www.blogcoward.com jdn

    “the codebase is only one of the items we show…”

    That’s fine. But isn’t what you’ve described true of any type of software development (that requires more than 2 people anyway)? Isn’t that true of TDD, for instance?

    I think Evans’ sample app disproves your point, but even without it, I don’t see what it is about DDD that makes it *especially* tied to ‘the journey’ as opposed to anything else.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @jdn

    Evans’ sample app is meant to accompany the book, not to replace it. You wouldn’t be able to look at the app and say “oh, that’s obviously DDD”.

    If you looked at the apps we’ve created, it’s only DDD if it came out of the domain. Understanding that it came out of the domain requires understanding about the domain.

    I say it’s tied to the journey simply because of experience of going through many different iterations over the model, the discovery process, and the refinement of the model. THAT’S the most valuable piece of DDD, IMO. It’s how we went about arriving at the model, the questions we asked, the modeling and learning sessions we had.

    It’s not that hard to type the technical patterns applied. Getting there through the analysis is much more difficult, that’s why I don’t see _as much_ value in the end product.

    I still talk a lot about the technical patterns, simply because it’s very hard to simulate discussions with a domain expert. I just try to push the values as much as possible, which means pushing the journey over the technical patterns.

  • ton

    Example isn’t another way to teach, it is the only way to teach.
    –Albert Einstein

    This comment explains alot about why people are seeking DDD examples. Its the BEST WAY to teach and reinforce concepts to others.

    ” If you’re looking for a DDD example, it’s Evans’ DDD book.”
    I really disagree strongly with this comment. Honestly speaking as an owner of Evans’ book it offers little in the way of concrete examples about how to pratice DDD. He really only offers a philosphy.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @ton

    So what would this example look like? A concrete example of DDD isn’t an application. That’s an example of patterns.

  • ton

    Well design patterns are used in software everyday. There is an entire book on design patterns with code examples from GOF. So if its an ‘example of patterns’ then concrete code examples can be produced representing the pattern.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @ton

    Let me rephrase that:

    If you’re looking for a “DDD sample”, you’re probably looking for “DDD pattern examples”. If you’re truly looking for a sample of how to do DDD, it’s not in any google code repository. Pattern examples are great, we should just be explicit about what it is and is not.

  • ton

    @bogardj
    I can accept that answer. I’ll just have to go back and reread master Evans’ book to find the ‘essence’ of DDD :-)

  • http://www.citerus.se Peter Backlund

    Hi, I’m a member of the sample application developer team at Citerus, and I think you’re making a number of really good points. DDD is not (only) a collection of patterns, and you can’t really understand/appreciate DDD from looking at the sample app code alone. Things like finding the ubiquitous language and exporing the model together with the domain experts and mapping the various bounded contexts are are not present in the code base.

    However, we do think that it adds value to the DDD community to have something that’s at least somewhat realistic to look at and talk about, and to apply different techniques to. At the end of the day, it’s all about creating software, so the code is never irrelevant. We’re trying to bridge the gap between theory and practice, to make DDD more accessible to developers.

    The cargo domain is familiar to anyone who has read the book and/or taken Eric’s (or Citerus’) course in DDD, so some of the missing aspects may be found in the book. Like you said, the application complements the book.

    One thing we’re hoping that people will do is to port is to different frameworks and platforms, and there are already two porting efforts under way (Sculptor* and Qi4j**), and there’s been talk about a .NET version.

    * http://fornax-platform.org/cp/x/aAQ
    ** http://www.qi4j.org/

  • http://fornax-platform.org/cp/x/aAQ Patrik Nordwall

    I have completed the Sculptor port of the DDD Sample. It is a really nice sample, since is based on something real, and complicated – the cargo domain. It was a good exercise to port it to Sculptor. Not very difficult, since Sculptor was designed with the DDD concepts from the beginning. I think it is a nice illustration of how to combine hand written code for the business logic with the automatically generated pieces provided by Sculptor.
    http://fornax-platform.org/cp/x/RQk

  • http://blog.dannynet.net Danny Lagrouw

    I agree, Evans’ book offers mostly best practice patterns for modelling and designing in a domain-driven way. Asking for examples would be asking for example domain models that use the patterns Evans describes.
    There is however another, less known DDD theory, that focuses more on the separation between domain model implementation and other architectural layers. Bastion (http://bastionframework.org) is a framework for applications set up this way. As such it could be seen as a real-life example of DDD. More background info on the ideas behind Bastion: http://www.blog.dannynet.net/archives/125.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Peter, @Patrik @Danny

    Thanks for the links! I’ll take a look. It was nice that some folks are putting out some samples based on the book, as the book goes fairly deep into a specific domain.

  • Arnis L.

    And where we have got so far?

    I still see misuse and misunderstanding of DDD ideas all around me. My experience ain’t brilliant either.

  • tong xuesheng

    Led light uses light-emitting diodes (LEDs ) as the light source, have longevity and low energy saving ,also without harmful substances to humen.Though the led lightings’initial purchase costs are more expensive than traditional lamps , in the long time, it is still worthy to buy them.