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

Figure 17.3. Structure imposed on the relationships of components of
distinct 
BOUNDED CONTEXTS
Suppose you want to adopt 
RESPONSIBILITY LAYERS
, but you have a legacy system whose
organization is inconsistent with your desired large-scale structure. Do you have to give up your
LAYERS
? No, but you have to acknowledge the actual place the legacy has within the structure. In
fact, it may help to characterize the legacy. The 
SERVICES
the legacy provides may in fact be
confined to only a few 
LAYERS
. To be able to say that the legacy system fits within particular
RESPONSIBILITY LAYERS
concisely describes a key aspect of its scope and role.
Figure 17.4. A structure that allows some components to span layers

---

If the legacy subsystem's capabilities are being accessed through a 
FACADE
, you may be able to
design each 
SERVICE
offered by the 
FACADE
to fit within one layer.
The interior of the Shipping Coordination application, being a legacy in this example, is presented
as an undifferentiated mass. But a team on a project with a well-established large-scale structure
spanning the 
CONTEXT MAP
could choose, within their 
CONTEXT
, to order their model by the same
familiar 
LAYERS
.
Figure 17.5. The same structure applied within a 
CONTEXT
 and across the
CONTEXT MAP
 as a whole

---

Of course, because each 
BOUNDED CONTEXT
is its own name space, one structure could be used to
organize the model within one 
CONTEXT
, while another was used in a neighboring 
CONTEXT
, and still
another organized the 
CONTEXT MAP
. However, going too far down that path can erode the value of
the large-scale structure as a unifying set of concepts for the project.
[ Team LiB ]

---

[ Team LiB ]