Bit by Bit

Domain Language

You need a domain language to design and implement domain models. As you know from strategic design, DDD has no such thing as a single definitive model and therefore no single domain language. Like any natural language, a domain language is characterized by dialects; it is ambiguous, context dependent, and subject to constant change.

However, technical models can only be expressed accurately with precise language and codified in software. In DDD, this precise language is known as the ubiquitous language. It is developed for each bounded context and based on a context-dependent subset of the domain language. The terms of the ubiquitous language are defined with sufficient precision (e.g., in a glossary) to describe requirements, to design the domain model of a bounded context, and to name business concepts in the code (e.g., a type of movie ticket).

In fact, this precision makes such a language ubiquitous. It is used in conversations, texts, diagrams, and code; prevents a conceptual break between domain and technical models (Figure 3); and facilitates communications with domain experts.

Figure 3: A class diagram with (left) and without (right) taking ubiquitous language into consideration.

A ubiquitous language is not simply the result of analysis and is not an upfront design. It emerges from discussions between the subject matter experts and the development teams. It evolves over time and then prompts refactoring in the code.

Ubiquitous language and domain models are not a one-way street from business to IT. Software development can generate new business ideas. To stick to the movie theater example, during the development of an online ticketing service, the notion of a recommendation based on previous purchase behavior can be fed back into the ubiquitous language of the bounded context.

Collaborative Modeling

How do you find good context boundaries and develop ubiquitous languages and domain models? Evans cites interviews, discussing specific scenarios, prototype implementations, and short feedback cycles. Beyond that, however, he provides aspiring DDD practitioners very few tools of the trade. This methodological gap for the analysis of domains and the design of application-oriented software was filled by others. Popular methods include event storming [6], domain storytelling [7], or example mapping [8].

These methods have in common the bringing together of development teams and subject matter experts who model collaboratively, which is why these workshop formats are grouped together under the term "collaborative modeling." The collaborative modeling toolbox is one of the most important additions to DDD, and the community is developing it intensively. Additionally, collaborative modeling can also be useful independent of DDD (e.g., when discovering requirements).

What DDD Is (Not)

DDD has become far more important in the past 20 years. However, widespread use is also accompanied by misunderstandings and exaggerated expectations, which should be cleared up now.

DDD is neither a framework, nor an architectural style, nor a method, because there are no rules on how to apply it. It is also not a waterfall method in which models are designed up front (see the "DDD and Agility" article by Eberhard Wolff in this issue). It is by no means necessary to use the technology throughout from the strategic to the tactical aspects. DDD doesn't force you to build microservices, nor does it conjure away complexity; complex subject matter remains complex even with DDD.

What DDD has at its core, on the other hand, is a set of principles [9]. To design software for complex subject matter, development teams (developers, testers, analysts, etc.) need to build a deep, shared understanding of the application domain. In the process, they are guided by subject matter experts. This understanding grows out of the language of the domain, which must be formalized in a joint process in a coordinated and unambiguous manner to create a ubiquitous language.

Understanding is expressed in a model shared by business experts and developers that describes the problem space (as opposed to the solution space). The model must explicitly express the essential complexity of the domain. Complex subject matter cannot be efficiently expressed through a single universal model and language, which makes it essential to break the subject matter down into bounded contexts. The model, language, and code need to evolve as the understanding of the domain grows. DDD is not necessarily applied everywhere, in the spirit of pragmatism, but where it will have the greatest effect.

I hope that this article has helped to communicate a clear idea of DDD. If you want to delve deeper, see the "Recommended Reading" box for my recommendations on the subject.