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

How Restrictive Should a Structure Be?
The large-scale structure patterns discussed in this chapter range from the very loose 
SYSTEM
METAPHOR
to the restrictive 
PLUGGABLE COMPONENT FRAMEWORK
. Other structures are possible, of
course, and even within a general structural pattern, there is a lot of choice about how restrictive
to make the rules.
For example, 
RESPONSIBILITY LAYERS
dictate a kind of factoring of model concepts and their
dependencies, but you could add rules that would specify communication patterns between the
layers.
Consider a manufacturing plant where software directs each part to a machine where it is
processed according to some recipe. The correct process is ordered from a Policy layer and
executed in an Operations layer. But inevitably there will be mistakes made on the factory floor.
The actual situation will not be consistent with the rules of the software. Now, an Operations layer
must reflect the world as it is
, which means that when a part is occasionally put in the wrong
machine, that information must be accepted unconditionally. Somehow, this exceptional condition
needs to be communicated to a higher layer. A decision-making layer can then use other policies
to correct the situation, perhaps by rerouting the part to a repair process or by scrapping it. But
Operations does not know anything about higher layers. The communication has to be done in a
way that doesn't create two-way dependencies from the lower layers to the higher ones.
Typically, this signaling would be done through some kind of event mechanism. The Operations
objects would generate events whenever their state changed. Policy layer objects would listen for
events of interest from the lower layers. When an event occurred that violated a rule, the rule
would execute an action (part of the rule's definition) that makes the appropriate response, or it
might generate an event for the benefit of some still higher layer.
In the banking example, the values of assets change (Operations), shifting the values of segments
of a portfolio. When these values exceed portfolio allocation limits (Policy), perhaps a trader is
alerted, who can buy or sell assets to redress the balance.
We could figure this out on a case-by-case basis, or we could decide on a consistent pattern for
everyone to follow in interactions of objects of particular layers. A more restrictive structure
increases uniformity, making the design easier to interpret. If the structure fits, the rules are likely
to push developers toward good designs. Disparate pieces are likely to fit together better.
On the other hand, the restrictions may take away flexibility that developers need. Very particular
communication paths might be impractical to apply across 
BOUNDED CONTEXTS
, especially in
different implementation technologies, in a heterogeneous system.
So you have to fight the temptation to build frameworks and regiment the implementation of the
large-scale structure. The most important contribution of the large-scale structure is conceptual
coherence, and giving insight into the domain. 
Each structural rule should make development
easier.
[ Team LiB ]

---

[ Team LiB ]