Eric Evans, author of Domain-Driven Design, said the concepts in the book he wrote in 2003 are even more relevant now than they were 14 years ago. As the range of tools and technologies has expanded, some lend themselves to the principles of DDD better…
Challenging the notion that the book he wrote in 2003 was still relevant, Eric Evans, author of Domain-Driven Design, said the concepts are even more relevant now than they were 14 years ago. His keynote presentation kicked off the Explore DDD conference in Denver, Colorado, which is the first-ever conference focused on Domain-Driven Design hosted in North America. Evans covered the major concepts of DDD in relation to the historical landscape of software development. As the range of tools and technologies has expanded, some lend themselves to the principles of DDD better than others we’ve had in the past. Evans said, “DDD is not about technology, but is not indifferent about technology.”
Looking back at the state of the art in 2003, we had Java and J2EE, SQL databases and Object-Relational Mappers, but not many choices beyond those. The lack of choice led to some tools being used because they were the only viable option. For example, Evans said ORMs were not meant to be the way we did everything, yet have persisted for ten to fifteen years. This is not to say that any tool, pattern, or architecture can’t be correct in some situations. Rather, Evans was frustrated when there is only one set of solutions applied indiscriminately. He also believes DDD has evolved over the past fourteen years, and said, “It would be a shame if we did DDD like I wrote it in the book.”
Many concepts in his DDD book were difficult to implement with the tools of the day, and have become easier with modern platforms. Evans admitted that one concept proposed in the book, making value objects immutable, was so difficult in the past that it was almost not worth doing. By comparison, functional languages make immutability easier. Similarly, the microservices movement has helped mark context boundaries, while NoSQL databases can manage aggregates better than relational databases. Always focused on tackling complexity at the heart of software, Evans applauded these advancements which facilitate writing software that expresses the model completely. “If the technology supports you in these things, you can focus on coming up with better models.”
Compromises and trade-offs in software are unavoidable, and Evans encouraged everyone to accept that “Not all of a large system is going to be well designed.” Just as “good fences make good neighbors,” bounded contexts shield good parts of the system from the bad. It therefore stands to reason that not all development will be within well-defined bounded contexts, nor will every project follow DDD. While developers often lament working on legacy systems, Evans places high value on legacy systems, as they are often the money makers for companies. His encouragement for developers to “hope that someday, your system is going to be a legacy system” was met with applause.
Evans also promoted open-source software, especially as a way to learn, sharing that he learned Smalltalk by reading examples. That sentiment matches the collaborative environment at Explore DDD, with one-third of the presentations dedicated to real-world case studies and people sharing their experiences implementing DDD.
Evans is pleased to see the winds shifting in favor of elegant design. His book was written to address the problems faced when a system couldn’t scale, resulting in a business that also couldn’t scale. As a self-fulfilling requirement, he said, “A need for cleaner design will create cleaner designs.”
