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

Itinerary
.
User:
You won't have to worry about this on origin or destination, since the 
Itinerary
would
always change then.
Developer:
Fine, but it will be simpler for us to just do the comparison every time. The 
Itinerary
will only be generated when the 
Route Specification
is no longer satisfied.
The second dialog conveys more of the intent of the domain expert. The user employed the word
"itinerary" in both dialogs, but in the second it was an object the two could discuss precisely,
concretely. They discussed the "route specification" explicitly, instead of describing it each time in
terms of attributes and procedures.
These two dialogs were deliberately constructed to closely parallel each other. Realistically, the
first would have been more verbose, bloated with explanations of application features and
miscommunications. The domain-model-based terminology of the second design makes the second
dialog more concise.
[ Team LiB ]

---

[ Team LiB ]
Modeling Out Loud
The detachment of speech from other forms of communication is a particularly great loss because
we humans have a genius for spoken language. Unfortunately, when people speak, they usually
don't use the language of the domain model.
That statement may not ring true for you initially, and indeed there are exceptions. But the next
time you attend a requirements or design discussion, really listen. You'll hear descriptions of
features in business jargon or layman's versions of the jargon. You'll hear talk about technical
artifacts and concrete functionality. Sure, you'll hear terms from the domain model; obvious nouns
in the common language from the business jargon will typically be coded as objects, and so those
terms will tend to be mentioned. But do you hear phrases that could even remotely be described in
terms of relationships and interactions in your current domain model?
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.
"If we give the 
Routing Service
an origin, destination, and arrival time, it can look up the
stops the cargo will have to make and, well . . . stick them in the database." (
vague and
technical
)
"The origin, destination, and so on . . . it all feeds into the