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

by Evans Eric

When the model objects couldn’t carry us through an important scenario, we brainstormed new ones or changed old ones, crunching their knowledge.

We refined the model; the cod...

As the team went through scenarios, the spoken expressions themselves provided a quick viability test of a proposed model, as the ear could quickly detect either the clarity and ease or the awkwardness of expression.

It is the creativity of brainstorming and massive experimentation, leveraged through a model-based language and disciplined by the feedback loop through implementation, that makes it possible to find a knowledge-rich model and distill it.

Effective domain modelers are knowledge crunchers.

They take a torrent of information and probe for the relevant trickle.

They try one organizing idea after another, searching for the simple view that ...

Many models are tried and rejected or...

Success comes in an emerging set of abstract concepts that makes sen...

Knowledge trickles in one direction, but does not accumulate.

but if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it.

Now an important business rule is hidden as a guard clause in an application method.

As written, it is unlikely that any business expert could read this code to verify the rule, even with the guidance of a developer.

It would be difficult for a technical, non-businessperson to connect the requirement text with the code.

We can change the design to better capture this knowledge.

The overbooking rule is a policy.

It will be clear to all that overbooking is a distinct policy, and the implementation of that rule is explicit and separate.

This example is meant to show that a domain model and corresponding design can be used to secure and share knowledge.

Programmers can show business experts technical artifacts, even code, that should be intelligible to domain experts (with guidance), thereby closing the feedback loop.

Rather than the logistics of the itinerary, what came to the fore were legal documents such as the bill of lading, and processes leading to the release of payments.

Our view of shipping changed from moving containers from place to place, to transferring responsibility for cargo from entity to entity.

New insight from moving containers from place to place into transferring responsibility of cargo from entity to entity

These terms and interrelationships provide the semantics of a language that is tailored to the domain while being precise enough for technical development.

The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.

The vocabulary of that UBIQUITOUS LANGUAGE includes the names of classes and prominent operations.

The LANGUAGE includes terms to discuss

rules that have been made explicit ...

roles. It may lack the semantic richness of the specialized jargons of the field.

But those jargons can’t be used unadulterated because they contain ambiguities and contradictions.

Committed to using this language in the context of implementation, the developers will point out imprecision or contradictions, engaging the domain experts in discovering workable alternatives.

Use the model as the backbone of a language.

Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model.

Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

One of the best ways to refine a model is to explore with speech, trying out loud various constructs from possible model variations. Rough edges are easy to hear.

It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modeling effort, just as it is vital to engage our visual/spatial reasoning by sketching diagrams.

Just as we employ our analytical abilities with methodical analysis and design, and that mysterious “feel” of the code.

These ways of thinking complement each other, and it takes all of them to find us...

Of all of these, experimenting with language is most ...

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.

Simple, informal UML diagrams can anchor a discussion.

Sketch a diagram of three to five objects central to the issue at hand, and everyone can stay focused.

Object interaction diagrams can illustrate some tricky hotspots in the design, but the bulk of the interactions can’t be shown that way.

is just too much work, both to create the diagrams and to

read ...

Diagrams are a means of communication and explanation, and they facilitate brainstorming.

They serve these ends best if they are minimal.

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

Always remember that the model is not the diagram.

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

If the managers perceive analysis to be a separate process, the development team may not be given adequate access to domain experts.

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.