Software Modeled on the Business It Serves
Domain-Driven Design (DDD) is an approach to software development that puts a rich model of the business domain at the center of the system. Rather than treating the underlying business logic as a secondary concern, DDD focuses on building software that reflects the actual processes, rules, and terminology of the domain it serves. The approach is well-suited to complex domains, where tangled and often messy logic needs structure.
The name comes from Eric Evans's 2003 book, which introduced the approach through a catalog of patterns. Since then, the community around DDD has grown, spawning further books and training courses that expand on the original ideas.
Beyond the Modeling Notations
The notion that software should be grounded in a well-developed model of its domain is hardly new—it has been around for decades. Practitioners like Jim Odell were developing this line of thinking throughout the 1980s and 1990s through work on data modeling, information engineering, and object-oriented analysis. This thread ran through much of the database and object-oriented communities during that era.
Evans's contribution was not inventing this way of thinking, but building a vocabulary to discuss it. He identified conceptual elements that went beyond the various diagramming notations that dominated the conversation at the time.
A Language for Both Code and Conversation
At the heart of DDD is the Ubiquitous Language: an embedding of domain terminology directly into the software itself. While the idea of developing such models was common practice, they were usually sketched on paper and expected to be completed up front. DDD instead stresses building the model in software and letting it evolve over the lifetime of the product. Evans is a strong proponent of Extreme Programming, and he sees DDD as a natural fit for an XP approach—a view widely shared by practitioners of both.
The book also introduced a classification of objects into Entities, Value Objects, and Service Objects—an important conceptual gap that programming languages and diagrammatic notations failed to fill. It likewise brought the notion of Aggregates into the conversation, clarifying how clusters of objects should be treated as a single unit.
Strategic Design for Large Domains
Arguably the most significant piece of DDD is its treatment of Strategic Design: organizing large, sprawling domains into a network of Bounded Contexts. Before DDD, this problem—how to partition a complex business domain into coherent and maintainable pieces—had not been tackled convincingly. It is also the part of DDD that is most easily applied regardless of underlying programming approach.
Despite coming out of the object-oriented community, the core notions of DDD are conceptual rather than technical. They translate well to just about any programming paradigm.
Further Reading
Evans's original book is often described as difficult to read, but it rewards the effort and belongs on any serious software developer's shelf. Vaughn Vernon's 2013 book is a sensible next step, one that covers later thinking in the community and focuses on strategic design.
