The DDD Community - Domain-Driven Design: The First 15 Years

Its rare for a software book to last fifteen years. By the time a new book gets out of beta, its already at risk of being obsolete. Eric Evans Domain-Driven Design Tackling Complexity in the Heart of Software (Addison-Wesley) is, over 15 years after its publication, sparking a renewed interest in software design. Books and blogs have expanded on the ideas proposed by Eric; people have created new methods to apply the principles; there are workshops and online courses; conferences in Europe, Asia, and North America; and dozens of meetups all over the world.

And where traditionally the DDD community used to be exclusively populated by programmers and architects, were now seeing growing attention from different disciplines in software design. Analysts seem to be leading the way a natural fit, as modelling has always been a fundamental part of analysis. But now testers and product designers are discovering the value of Domain-Driven Design. They too deal in models, and are attracted to the principles and methods of building and collaborating on models, of sharing a Ubiquitous Language, and of finding better context boundaries for managing the growing complexity of software.

What makes the success of DDD even more surprising is that Erics book has a reputation of being theoretical, academic, or philosophical; terms used by programmers when they simply mean hard. It has to be: it was extraordinarily ambitious to write a book that deals with complexity from the smallest domain object to large scale structures. DDD is hard because software design is hard. Once you get used to the density of knowledge in Erics book, youll find it is in fact highly practical. The ideas originated in the real world, in highly complex environments, and are hardened by years of deep thinking, discussions, and experiments.

DDD is not done. Last Summer, during a dinner in Paris, Eric spoke about how hed love to see more publications about Domain-Driven Design. Theres no lack of interesting new ideas in this community, but they are dispersed over talks, blogs, Twitter, and mailing lists. So to celebrate DDDs 15th anniversary, we couldnt think of a better idea than to make this book. We hope it will inspire others to develop new ideas and to write.

When we approached authors for this book, we deliberately imposed as few constraints as possible. The result is a highly diverse collection of essays. Some authors have been there since the start of Domain-Driven Design, others are fairly new to this community. Some entries were written specifically for this book, others are adaptations from older work Martin Fowlers entry, not coincidentally, even predates DDD. The topics are eclectic as well, from philosophical meanderings to deep technical discussions, from tried and true methods to experimental ideas, from critical analysis to DDD love letters.

Eric, we present this book to you during the Domain-Driven Design Europe 2019 conference, as a token of our appreciation for your generosity in sharing your ideas. Heres to the next 15 years!

Mathias Verraes

Founder Domain-Driven Design Europe

Id like to thank Anneke Schoonjans, Cline Dursin, Paul Rayner, and Indu Alagarsamy for their help with the logistics and content of this book. The wonderful cover design is by Nick Liefhebber. And most importantly, Im incredibly thankful for the more than 20 authors who contributed to this book. You are all people who have in one way or another inspired me, and countless others.

Domain-Driven Design Europe is the worlds leading DDD conference. Our mission is to expose the community to new ideas and influences from inside and outside the DDD community, and to spread DDD throughout the software industry. Please visit the DDD Europe site to learn more, and we hope to welcome you as a participant soon.

Corrections or comments can be submitted via GitHub or to the authors directly.

Distilling DDD Into First Principles Scott Millett

Parts of this essay first appeared in the book Patterns, Principles, and Practices of Domain-Driven Design (Wrox 2015) by Scott Millett and Nick Tune.

If I could offer you one piece of advice (apart from always wear sunscreen), it would be to do your utmost to move beyond simply understanding your domain and get to a position where you are in sync with your business vision, goals, strategy and constraints. You should share the same worries as your business counterparts: are we going to hit budget? how do we successfully launch our proposition in a new territory? how do we remove the bottleneck in fulfillment? If you are able to move to a more fundamental level of understanding for your business then you should be in a position that not only gives you a deeper level of understanding for your domain, enabling you to produce effective solutions, but will also allow you to proactively identify product opportunities that offer true business value.

It should come as no surprise to you that software is eating the world and that IT is now a crucial capability in any organisation. However most technical teams only seem to have a shallow understanding of the domain they work within and in my experience are more focused on tech for techs sake over the overall strategy and needs of a business. Advances in technology have afforded a huge amount of opportunity for business development and evolution, however the majority of businesses are yet to catch up on these opportunities. This is not due to a lack of technical savviness from business colleagues but more from a lack of alignment from technical people, those that understand the art of the possible, which prevents them from seeing opportunities.

The line between the non-technical and technical people within modern businesses is blurring. I am seeing more progressive companies that have blended roles where technical people have a seat at the table. They have a seat because they have earnt it through leveraging the art of the possible, technical opportunities, to remove a constraint on the production of business value. They are aligned to the real needs of the business and they have the autonomy to deliver solutions to meet those needs.

This essay is about my story and how DDD helped me learn more about solving problems and helping people to refocus efforts on how solutions are derived, how people communicate and collaborate, and how technical people can deliver solutions and identify opportunities that exceed expectations of business colleagues.