Eric Evans, Domain Language

Many development teams undertake modeling, yet they often end up with little more than a data schema which does not deliver on the productivity promises for object design. What does it take to make a domain model truly pull its weight and positively transform a project? To do that we need a model that is not just a diagram or an analysis artifact, but that provides the very foundation of the design, the driving force of analysis, even the basis of the language spoken on the project.

This talk will outline some of the foundations of domain-driven design: How models are chosen and evaluated; How multiple models coexist; How the patterns help avoid the common pitfalls, such as overly interconnected models; How developers and domain experts together in a domain-driven design team engage in progressively deeper exploration of their problem domain and make that understanding tangible as a practical software design.

Some design decisions have an impact on the trajectory of the whole project. Modeling is most needed in complex circumstances, yet the typical dynamics of large projects too often derail it or disconnect it from the real design. Conversely, modeling is best carried out by small, dynamic teams with a lot of autonomy, yet creating large systems requires coordination and project-spanning decisions. Managers and developers alike need to pay close attention to this intersection of design, project organization, and politics.

This talk briefly introduces two broad principles for strategic design: 'Context mapping' addresses a vital fact of life: different groups model differently. Ignoring these realities leads to dumbed-down models and costly, buggy integrations, and disruption of project plans where they depend on other teams.

Distilling a shared vision of the system's "core domain" and distinguishing the roles of supporting subdomains focuses development effort on real business assets, and provides a systematic guide to when "good enough" is good enough versus when to push for excellence.

There is a deep connection between modeling and language. This is why a central principle of domain-driven design is the "ubiquitous language". A shared conceptual model of the domain coevolves with a language used by all the people of the project, both technical and nontechnical, to talk about the domain and the design, and also to shape the implementation. Different implementation technologies provide us different forms and degrees of expressiveness, the most familiar being object-oriented programming, where class names and method names allow certain kinds of concepts to be named and manipulated explicitly. But the richness and fluency of the ubiquitous language can only be crudely rendered in the object-oriented medium. Domain-specific languages hold out the prospect of to express models and application logic in far better suited language.

This potential has not been fulfilled yet, but we are in a period now when increased attention and effort is focusing on the DSL approach. If we succeed, DSLs will no doubt take many forms to address many needs. This talk will focus on the particular context of complex business applications for enterprise systems and similar kinds of software.

The speaker will discuss how the programming expression of the ubiquitous language interacts with its other forms in domain-driven design projects, and consider how DSL techniques could enhance this, possibly making a major advance in toward the goals of DDD: evolving a deep understanding of the domain, distilled as a model, and expressed in software.