Editor's note, 2018-10-08: The video recording of this presentation is now available on the Explore DDD YouTube channel.
During his "skeptical, optimistic, and pragmatic" keynote presentation at Explore DDD 2018, Eric Evans said "DDD isn't done." The author of Domain-Driven Design reflected on the fifteen years since the book was published, expressing some surprise that the idea has been so popular for so long. He emphasized that DDD hasn't stood still over all those years, and many people are responsible for continual innovation. He also said there is still much to do to keep DDD evolving.
Evans is frequently asked to define DDD, which leads him to wonder how tightly DDD should be defined. On one end of the spectrum lies "handwavy good advice" that is really just "feel good mush." The other extreme is a trivial "cookbook" that must be rigidly followed, yet can become irrelevant for dealing with higher concepts. Evans believes there is a sweet spot for DDD. When guidance is so rigid that even the slightest change says, "you're not doing DDD," then you can't really innovate. For DDD to remain relevant, it must allow for innovation and evolution.
Evans reminded the audience of the main guiding principles of DDD: Focus on the core domain; explore models in a creative collaboration of domain practitioners and software practitioners; and speak a ubiquitous language within an explicitly bounded context. From a skeptical viewpoint, he then asked, "What if we are wrong?" If we don't see DDD providing the expected results, then, as professionals, we need to reexamine our principles.
Acknowledging some teams have had disappointing results with DDD, Evans tried to categorize the reasons for those results. In some cases, the culture wasn't supportive, while in others the culture may have been acceptable, but the team lacked the skills to be successful. Sometimes, it was simply a matter of bad luck, or came down to mysterious unknown causes, not worth the investigation into a possibly misleading root cause. Evans also raised the possibility that there are weak techniques in typical DDD, or that the DDD principles are flawed. If the techniques are weak, that can be addressed without changes to the fundamental principles of DDD. For example, Event Storming is a powerful technique that can help get collaboration started. However, if the principles are indeed flawed, are we able to flex them a bit without abandoning DDD entirely? This was left as an open question for consideration.
Evans sees many ways that DDD has evolved over the past fifteen years. Technical patterns such as event sourcing and CQRS have changed how we built software, and provided the idea that systems did not need a single database. Books, blogs and other writing have provided new perspectives and helpful explanations, expanding on Evans' original ideas. A major difference is the growth of a community around DDD, with local meetups and international conferences, including Explore DDD and DDD Europe.
The growth of microservices has to be given some of the credit for the renewed appreciation of DDD in the past few years. Evans saw this as positive, but also stressed a bit of caution. Although DDD conferences probably wouldn't be happening now if not for microservices, prescriptive guidance such as "each microservice is a bounded context" approaches the "cookbook" end of the spectrum, and diverges from the sweet spot of DDD.
A new metaphor Evans introduced was comparing a large software system to a community garden. Looking past the obvious bounded contexts of people sharing space in the garden, he sees positive analogies to legacy systems, looking at the "abundance of maturity." Gardens are most valuable in late summer, when they are most productive. However, that is long past the stage when you can easily make changes to the garden, in early spring. Similarly, the most malleable phase for software is not when it is the most productive.
Evans' final point was that the secret to moving forward with DDD is collaboration. He sees conferences as being most effective as opportunities to bring experts together, to discuss ideas and learn from each other, rather than simply being a broadcast and lecture format. He advocated for DDD experts to conduct experiments, and share those experiments and results within the DDD community. It's equally important to bring in experts and opinions from other domains, such as authors of libraries and languages. He concluded by stating, "DDD has been shaken up a few times in the past 15 years. I think it's time for another big shakeup."