Agile Zone is brought to you in partnership with:

Gojko Adzic runs Neuri Ltd, a UK-based consultancy that helps companies build better software by introducing agile practices and tools and improving communication between software implementation teams, stakeholders and clients. The focus of his work over the last several years has been implementing and improving the practice of Agile Acceptance Testing. Gojko frequently gives public talks on that topic and other agile development topics. He is the author of Test Driven .NET Development with FitNesse, published by Neuri Limited in 2008, and more than 200 articles published in various magazines. Gojko has posted 6 posts at DZone. View Full User Profile

Domain driven design redefined

06.24.2010
| 6540 views |
  • submit to reddit

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.

References
Published at DZone with permission of its author, Gojko Adzic. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

John DeHope replied on Fri, 2010/06/25 - 2:16pm

A great synopsis. I've always felt DDD had an unfortunate fetish in detailing the difference between entity and value types. I'm glad somebody is working to narrow the focus.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.