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

Developer:
That's just a report, I think. We won't be able to base the operations application on
that.
[
Developer
looks thoughtful, then excited.
]
Developer:
So, this itinerary is really the link between booking and operations.
Expert:
Yes, and some customer relations, too.
Developer:
[
Sketching a diagram on the whiteboard.
] So would you say it is something like this?
Expert:_Yes,_that_looks_basically_right._For_each_leg_youd_like_to_see_the_vessel_voyage,_the_load_and_unload_location,_and_time._Developer'>Figure 9.2.
Expert:
Yes, that looks basically right. For each leg you'd like to see the vessel voyage, the load
and unload location, and time.
Developer:
So once we create the 
Leg
object, it can derive the times from the vessel voyage
schedule. We can make the 
Itinerary
object our main point of contact with the operations
application. And we can rewrite that itinerary report to use this, so we'll get the domain logic back
into the domain layer.
Expert:
I didn't follow all of that, but you are right that the two main uses for the 
Itinerary
are in
the report in booking and in the operations application.
Developer:
Hey! We can make the 
Routing Service
interface return an itinerary object instead
of putting the data in the database table. That way the routing engine doesn't need to know about
our tables.
Expert:
Huh?
Developer:
I mean, I'll make the routing engine just return an 
Itinerary
. Then it can be saved in
the database by the booking application when the rest of the booking is saved.
Expert:
You mean it isn't that way now?!
The developer then went off to talk with the other developers involved in the routing process. They
hashed out the changes to the model and the implications for the design, calling on the shipping
experts when needed. They came up with the diagram in Figure 9.3.
Figure 9.3.

---

Next, the developers refactored the code to reflect the new model. They did it in a series of two or
three refactorings, but in quick succession, within a week, except for simplifying the itinerary
report in the booking application, which they took care of early the following week.
The developer had been listening closely enough to the shipping expert to notice how important
the concept of an "itinerary" was to him. True, all the data was already being collected, and the
behavior was implicit in the itinerary report, but the explicit