Domain-Driven Design: Tackling Complexity in the Heart of Software

by Evans Eric

But do you hear phrases that could even remotely be described in terms of relationships and interactions in your current domain model?

“A Routing Service finds an Itinerary that satisfies a Route Specification.”

our brains seem to be somewhat specialized for dealing with complexity in spoken language

pidgin

When people are talking, they naturally discover differences in interpretation and the meaning of their words, and they naturally resolve those differences. They find rough spots in the language and smooth them out.

Play with the model as you talk about the system. Describe scenarios out loud using the elements and interactions of the model, combining concepts in ways allowed by the model. Find easier ways to say what you need to say, and then take those new ideas back down to the diagrams and code.

Technical people often feel the need to “shield” the business experts from the domain model. They say: “Too abstract for them.” “They don’t understand objects.” “We have to collect requirements in their terminology.” These are just a few of the reasons I’ve heard for having two languages on the team. Forget them.

If sophisticated domain experts don’t understand the model, there is something wrong with the model.

As the new language evolves, the domain experts must make the extra effort to adopt it, and to retrofit any old documents that are still important.

The domain experts can use the language of the model in writing use cases, and can work even more directly with the model by specifying acceptance tests.

The meanings of words are slippery things. The domain model will typically derive from the domain experts’ own jargon but will have been “cleaned up,” to have sharper, narrower definitions.

Multiplicity of languages is often necessary, but the linguistic division should never be between the domain experts and the developers.

UBIQUITOUS LANGUAGE is cultivated in the intersection of jargons.

Simple, informal UML diagrams can anchor a discussion.

The trouble comes when people feel compelled to convey the whole model or design through UML. A lot of object model diagrams are too complete and, simultaneously, leave too much out. They are too complete because people feel they have to put all the objects that they are going to code into a modeling tool. With all that detail, no one can see the forest for the trees.

Object interaction diagrams can illustrate some tricky hotspots in the design, but the bulk of the interactions can’t be shown that way. It is just too much work, both to create the diagrams and to read them. And an interaction diagram can still only imply the purpose behind the model.

This needn’t trouble us, though, because careful use of English (or Spanish, or whatever) can fill this role pretty well.

Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.

It leads us toward simplified diagrams of conceptually important parts of the object model that are essential to understanding the design. The diagrams in this book are typical of those I use on projects. They simplify, they explain, and they even incorporate a bit of nonstandard notation when it clarifies their point.

The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.

Supplemental diagrams and documents can guide people’s attention to the central points.

Rather than a diagram annotated with text, I write a text document illustrated with selective and simplified diagrams.

Once a document takes on a persistent form, it often loses its connection with the flow of the project. It is left behind by the evolution of the code, or by the evolution of the language of the project.

But code as a design document does have its limits. It can overwhelm the reader with detail.

A document shouldn’t try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior.

A document must be involved in project activities. The easiest way to judge this is to observe the document’s interaction with the UBIQUITOUS LANGUAGE. Is the document written in the language people speak on the project (now)? Is it written in the language embedded in the code?

If it is having no impact on the UBIQUITOUS LANGUAGE, something is wrong.

The UBIQUITOUS LANGUAGE allows other documents, such as requirements specifications, to be more concise and less ambiguous. As the domain model comes to reflect the most relevant knowledge of the business, application requirements become scenarios within that model, and the UBIQUITOUS LANGUAGE can be used to describe such a scenario in terms that directly connect to the MODEL-DRIVEN DESIGN (see Chapter 3). As a result, specifications can be written more simply, because they do not have to convey the business knowledge that lies behind the model.

By keeping documents minimal and focusing them on complementing code and conversation, documents can stay connected to the project. Let

behavior

and it won't express the user activity supported or elicited by it

It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.

Still, while even code can mislead, it is closer to the ground than other documents. Aligning the behavior, intent, and message of code using current standard technology requires discipline and a certain way of thinking about design

Models can also be valuable as education aids to teach about the domain.

An explanatory model can include aspects of the domain that provide context that clarifies the more narrowly scoped model.

The project had a domain model, but what good is a model on paper unless it directly aids the development of running software?

you couldn’t gain much insight about the purpose of the system by reading the code. Neither process took any advantage of the object paradigm available in their development environment, except as fancy data structures.

What is less obvious is that domain-driven design requires a different approach to modeling. . . .

The astrolabe was a mechanical implementation of an object-oriented model of the sky.

Projects that have no domain model at all, but just write code to fulfill one function after another, gain few of the advantages of knowledge crunching and communication discussed in the previous two chapters. A complex domain will swamp them.

On the other hand, many complex projects do attempt some sort of domain model, but they don’t maintain a tight connection between the model and the code. The model they develop, possibly useful as an exploratory tool at the outset, becomes increasingly irrelevant and even misleading. All the care lavished on the model provides little reassurance that the design is correct, because the two are different.

This connection can break down in many ways, but the detachment is often a conscious choice. Many design methodologies advocate an analysis model, quite distinct from the design and usually developed by different people. It is called an analysis model because it is the product of analyzing the business domain to organize its concepts without any consideration of the part it will play in a software system. An analysis model is meant as a tool for understanding only; mixing in implementation con...

Some knowledge crunching happens during such an analysis, but most of it is lost when coding begins, when the developers are forced to come up with new abstractions for the design.

crucial discoveries always emerge during the design/implementation effort.

Very specific, unanticipated problems always arise.

An up-front model will go into depth about some irrelevant subjects, while it overlook...

Whatever the cause, software that lacks a concept at the foundation of its design is, at best, a mechanism that does useful things without explaining its actions.

A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.

MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes. Setting

This approach demands a model that works well as both analysis and design. When a model doesn’t seem to be practical for implementation, we must search for a new one. When a model doesn’t faithfully express the key concepts of the domain, we must search for a new one. The modeling and design process then becomes a single iterative loop.

It calls for hard thinking and usually takes multiple iterations and a lot of refactoring, but it makes the model relevant.