Today at the DDD Exchange 2010 mini-conference in London, Eric Evans spoke about emerging themes in the domain driven design community. Six years after the DDD book was published, Evans said that he can now define it more precisely than before.

“Anything can be called agile, anything can be called SOA – when anything can be called that it’s no longer a useful term”, said Evans. So he wanted to offer a new, precise definition of DDD, which defies “what it is, what it isn’t, while still leaving enough space for innovation.”

Evans said that one way to define DDD is as a set of driving principles:

  • Focus on the core domain — “people get distracted by technology and we want to bring that attention back to the business domain”, said Evans. Even that whole business domain is too much to focus, according to him, and DDD requires us to focus on the core, the critical, most valuable part.
  • Explore models in a creative collaboration with domain practitioners and software practitioners – “we have to collaborate, not just quiz [business experts] for requirements”.
  • Speak a Ubiquitous Language in an explicitly Bounded Context

Speaking about the focus on core domains, Evans said that that has to be something very specific.”We want to focus with collaborative cooperation on our core domain - we don’t want to give the same kind of attention to invoicing in most companies”, said Evans. Giving an example of eBay, he said that it is easy to assume that online auctions are the core domain but that would be wrong. He compared Amazon and eBay, and said that you can buy books in both places and they have similar features, but their core domains are very different. For eBay, it’s the rating of the seller - this is what makes eBay effective. “A star rating tells me that lots of people did business with a seller and I trust that. Developing trust between a buyer and a seller is a subdomain of online auctions, and their approach to building trust is part of the core domain of eBay. eBay would not have been today if they didn’t get that right”, said Evans.

Another way to define DDD, Evans said, is that it is a pattern language. It is a set of interrelated problem/solution pairs that have helped teams realise the principles. It also gives us a language, a vocabulary, that allows us to discuss domain modelling and design clearly. According to Evans, this is the key to enable innovation and keep the definition of DDD precise. There is a lot of innovation going on at the moment in the community, especially around architectural practices, and one of the key things for DDD in the future will be embracing those innovations. “I don’t want to say what the best way to do domain driven design is – others will present genuine advancements but none of us will be even able to understand it if we don’t speak the same language”, said Evans, continuing that he wants to hold on to the position of the final arbiter of the terminology used by the community.

The building blocks (entities, value objects…) aren’t really key to DDD, although most people initially thought that this is what DDD is about, said Evans. Having said that, he suggested that there is a lot of innovation in the community especially around aggregates, services and domain events, and that these concepts will be important for applying DDD in the future.

Related post: QCon London 2009: Eric Evans – What I’ve learned about DDD since the book