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

Exploration Teams
Whatever the source of dissatisfaction, the next step is to seek a refinement that will make the
model communicate clearly and naturally. This might require only some modest change that is
immediately evident and can be accomplished in a few hours. In that case, the change resembles
traditional refactoring. But the search for a new model may well call for more time and the
involvement of more people.
The initiators of the change pick a couple of other developers who are good at thinking through
that kind of problem, who know that area of the domain, or who have strong modeling skills. If
there are subtleties, they make sure a domain expert is involved. This group of four or five people
goes to a conference room or a coffee shop and brainstorms for half an hour to an hour and a half.
They sketch UML diagrams; they try walking through scenarios using the objects. They make sure
the subject matter expert understands the model and finds it useful. When they find something
they are happy with, they go back and code it. Or they decide to mull it over for a few days, and
they go back and work on something else. A couple of days later, the group reconvenes and goes
through the exercise again. This time they are more confident, having slept on their earlier
thoughts, and they reach some conclusions. They go back to their computers and code the new
design.
There are a few keys to keeping this process productive.
Self-determination
. A small team can be assembled on the fly to explore a design problem.
The team can operate for a few days and then disband. There is no need for long-term,
elaborate organizational structures.
Scope and sleep
. Two or three short meetings spaced out over a few days should produce a
design worth trying. Dragging it out doesn't help. If you get stuck, you may be taking on too
much at once. Pick a smaller aspect of the design and focus on that.
Exercising the 
UBIQUITOUS LANGUAGE
. Involving the other team members—particularly the
subject matter expert—in the brain-storming session creates an opportunity to exercise and
refine the 
UBIQUITOUS LANGUAGE
. The end result of the effort is a refinement of that 
LANGUAGE
which the original developer(s) will take back and formalize in code.
Earlier chapters in this book have presented several dialogs in which developers and domain
experts probe for better models. A full-blown brainstorming session is dynamic, unstructured, and
in-credibly productive.
[ Team LiB ]

---

[ Team LiB ]