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

Listen to Language
You may remember an experience like this: The users have always talked about some item on a
report. The item is compiled from attributes of various objects and maybe even a direct database
query. The same data set is assembled in another part of the application in order to present or
report or derive something. But you have never seen the need for an object. Probably, you have
never really understood what the users meant by a particular term and had not realized it was
important.
Then suddenly a light comes on in your head. The name of the item on that report designates an
important domain concept. You talk excitedly with your experts about your new insight. Maybe
they show relief that you finally got it. Maybe they yawn because they've taken it for granted all
along. Either way, you start to draw model diagrams on the board that fill in for some hand waving
that you've always done before. The users correct you on the details of how the new model
connects, but you can tell that there is a change in the quality of the discussion. You and the users
understand each other more precisely, and demonstrations of model interactions to solve specific
scenarios have become more natural. The language of the domain model has become more
powerful. You refactor the code to reflect the new model and find you have a cleaner design.
Listen to the language the domain experts use. Are there terms that succinctly state
something complicated? Are they correcting your word choice (perhaps
diplomatically)? Do the puzzled looks on their faces go away when you use a particular
phrase? These are hints of a concept that might benefit the model.
This is 
not
the old "nouns are objects" notion. Hearing a new word produces a lead, which you
follow up with conversation and knowledge crunching, with the goal of carving out a clean, useful
concept. When the users or domain experts use vocabulary that is nowhere in the design, that is a
warning sign. It is a doubly strong warning when both the developers and the domain experts are
using terms that are not in the design.
Or perhaps it is better to look at it as an opportunity. The 
UBIQUITOUS LANGUAGE
is made up of the
vocabulary that pervades speech, documents, model diagrams, and even code. If a term is absent
from the design, it is an opportunity to improve the model and design by including it.