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

Cargo's
AGGREGATE
boundary. It also required the addition of the
Handling Event Repository
, but it did not call for any redesign of the 
Handling Event
itself
(although some implementation changes might be involved, depending on the details of the
REPOSITORY
framework).
[ Team LiB ]

---

[ Team LiB ]
M
ODULES
 in the Shipping Model
So far we've been looking at so few objects that modularity is not an issue. Now let's look at a
little bigger part of a shipping model (though still simplified, of course) to see its organization into
MODULES
that will affect the model.
Figure 7.7 shows a model neatly partitioned by a hypothetical enthusiastic reader of this book.
This diagram is a variation on the infrastructure-driven packaging problem raised in Chapter 5. In
this case, the objects have been grouped according to the pattern each follows. The result is that
objects that conceptually have little relationship (low cohesion) are crammed together, and
associations run willy-nilly between all the 
MODULES
(high coupling). The packages tell a story, but
it is not the story of shipping; it is the story of what the developer was reading at the time.
Figure 7.7. These 
MODULES
 do not convey domain knowledge.

---

Partitioning by pattern may seem like an obvious error, but it is not really any less sensible than
separating persistent objects from transient ones or any other methodical scheme that is not
grounded in the meaning of the objects.
Instead, we should be looking for the cohesive concepts and focusing on what we want to
communicate to others on the project. As with smaller scale modeling decisions, there are many
ways to do it. Figure 7.8 shows a straightforward one.