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

Itinerary
as part of the model opened
up opportunities.
Benefits of refactoring to the explicit 
Itinerary
object:
Defining the interface of the 
Routing Service
more expressively
1.
Decoupling the 
Routing Service
from the booking database tables
2.
Clarifying the relationship between the booking application and the operations support
application (the sharing of the 
Itinerary 
object)
3.
Reducing duplication, because the 
Itinerary
derives loading/unloading times for both the
booking report and the operations support application
4.
Removing domain logic from the booking report and placing it in the isolated domain layer
5.
Expanding the 
UBIQUITOUS LANGUAGE
, allowing a more precise discussion of the model and
design between developers and domain experts and among the developers themselves
6.

---

6.
Scrutinize Awkwardness
The concept you need is not always floating on the surface, emerging in conversation or
documents. You may have to dig and invent. The place to dig is the most awkward part of your
design. The place where procedures are doing complicated things that are hard to explain. The
place where every new requirement seems to add complexity.
Sometimes it can be hard to recognize that there even is a missing concept. You may have objects
doing all the work but find some of the responsibilities awkward. Or, if you do realize something is
missing, a model solution may elude you.
Now you have to actively engage the domain experts in the search. If you are lucky, they may
enjoy playing with ideas and experimenting with the model. If you are not that lucky, you and
your fellow developers will have to come up with the ideas, using the domain expert as a validator,
watching for discomfort or recognition on his or her face.