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

Figure 16.22. Payroll is now explicit, distinct from Employee Type.
Figure 16.23. Each Employee Type now has a Retirement Plan and a
Payroll.
K
NOWLEDGE LEVEL
was hinted at by the characteristic access restrictions and a "thing-thing" type
relationship. Once it was in place, the clarity it afforded helped produce another insight that
disentangled two important domain concepts by factoring out 
Payroll
.
K
NOWLEDGE LEVEL
, like other large-scale structures, isn't strictly necessary. The objects will still
work without it, and the insight that separated 
Employee Type
from 
Payroll
could still have
been found and used. There may come a time when this structure doesn't seem to be pulling its
weight and can be dropped. But for now, it seems to tell a useful story about the system and helps
developers grapple with the model.
At first glance, 
KNOWLEDGE LEVEL
looks like a special case of 
RESPONSIBILITY LAYERS
, especially the
"policy" layer, but it is not. For one thing, dependencies run in both directions between the levels,
but with 
LAYERS
, lower layers are independent of upper layers.
In fact, 
KNOWLEDGE LEVEL
can coexist with most other large-scale structures, providing an
additional dimension of organization.
[ Team LiB ]

---

[ Team LiB ]
Pluggable Component Framework
Opportunities arise in a very mature model that is deep and distilled. A 
PLUGGABLE COMPONENT
FRAMEWORK
usually only comes into play after a few applications have already been implemented in
the same domain.
When a variety of applications have to interoperate, all based on the same abstractions
but designed independently, translations between multiple