Attendees (Left to right): Paul Rayner, Randy Stafford, Eric Evans, Udi Dahan, Alberto Brandolini, Greg Young, Jimmy Nilsson, Niclas Hedhman, Vaughn Vernon. Down in front (and our photographer) Martin Fowler.
We Held a DDD Summit
by Eric Evans (from the Domain Language Newsletter)
In May a handful of the top leaders and innovators in DDD joined me for three days to discuss the state of DDD and where it is going.
Of course, there are many people in the community whose leadership and innovations would have justified an invitation, and naturally not everyone I invited was able to come. Nonetheless, I think that the attendees managed to represent most of the major threads of the DDD community.
Our community has had some great events (such as DDD Exchange ) where attendees have had the chance to interact and hear from leaders. However, this was different. It was the first time we were able to bring together a critical mass of DDD leaders and innovators to talk intensively with each other. And it was time.
Right now we have a number of creative directions in DDD that have not quite been fit together. We have brilliant people driving those different ideas that are having trouble understanding each other. DDD is more energized than ever, yet it isn’t clear where we have consensus, where we really disagree, and where we have different approaches that work in different situations. Email, online discussion, and random one-on-one encounters at conferences have their limits. So ten of us made a rendezvous in Portland, Maine.
Our discussions were stimulating and also stressful. The process of connecting a group of strong-willed creative people, who have all been successful with their own approaches, produces both light and heat. We interspersed round-table discussions and smaller work-groups with long walks along the Maine sea shore. By constantly recombining ourselves, we tried to get past the kind of impasse that can stop two people or a fixed group.
Our discussions were a microcosm of the confusions in the community, and underneath it all we share some
fundamental passions. By day three it was clear we were making real progress and also that the work needed to continue well beyond our brief meeting. Furthermore, we wanted to involve the broader community, and in particular those leaders who were not involved.
There were a few particular goals set by those who attended. I hope that there will be follow-through and also community involvement. There was a lot of interest in drafting a statement of some of the principles we agree on. Also, we would like to put together some clear explanations of the value of DDD, aimed at a variety specific audiences, such as IT managers, architects, and analysts.
There was interest in producing a set of prescriptive rules of thumb for common design decisions in how to execute a domain-driven design. (To give an example, we agreed that it is best that all references from an aggregate to another aggregate be ids, not pointers, although either would comply with the definition of aggregate. Doing this will usually give better results for several reasons.) Having a set of such cook-book rules is not a substitute for design expertise, but it can help as people climb the
learning curve. And even an expert should have a reason for departing from the norm, so these rules of thumb could make routine decisions more standardized.
>[Update 10/2/11: The first such essay has now been published -- Effective Aggregate Design by Vaughn Vernon.]
Another identified need was to maintain a strong alignment of the basic definitions of terms. To me, this seems critical, and it is an area where we are further along.
Although it is healthy in a community to have multiple viewpoints on how to approach particular problems, we cannot effectively discuss those alternative views without a common language. This was one of the basic motivations of DDD in the first place – to enrich the language of software development teams to improve their capability of working together and clearly discussing decisions on modeling and design. I would say we are not in bad shape over all, but discrepancies of interpretation have
emerged. Conversations can expose discrepancies and, with a lot of persistence, they can be ironed out. Language alignment is never perfect, and we simply have to keep at it. One resource that I’ve worked on to try to help is the DDD Reference . You can download this free summary of each pattern in my book, as well as the few additional patterns that have become prominent in DDD in the past eight years. Some of these summaries are lifted directly out of the book, while some have been refined over the years. (These refinements are not, I hope, changes to the definitions, but clearer ways of explaining them.)
This DDD Reference can be an anchor point for the definitions in our shared language, and as discrepancies emerge and are resolved, I’ll do my best to reflect that in the document. My intent will be to keep the terminology stable, even as people innovate around the techniques. So when a genuinely new concept emerges, we can explain and debate it clearly. When necessary, we should carve out a new term, rather than bending the definition of an old one. Also, I have seen a tendency over the years for terms to become more concrete and specific in their usage. I believe we should, in most cases, pull ourselves back toward the broad abstractions that I tried to describe in my book. These will be more enduring as things change.
Over the next few months, you’ll hear from other attendees about the summit and I hope that drafts of the documents I mentioned will become available on the DDD Community site [on this page]. This event was meant to be the beginning of a new phase of the discussion of DDD. Please stay tuned.