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

Example
Employee Payroll and Pension, Part 2: K
NOWLEDGE
 L
EVEL
Our team members are back, and, refreshed from a night's sleep, one of them has started to close
in on one of the awkward points. Why were certain objects being secured while others were freely
edited? The cluster of restricted objects reminded him of the 
KNOWLEDGE LEVEL
pattern, and he
decided to try it as a way of viewing the model. He found that the existing model could already be
viewed this way.
Figure 16.21. Recognizing the 
KNOWLEDGE LEVEL
 implicit in the existing
model
The restricted edits were in the 
KNOWLEDGE LEVEL
, while the day-to-day edits were in the
operational level. A nice fit. All the objects above the line described types or longstanding policies.
The 
Employee Type
effectively imposed behavior on the 
Employee
.
The developer was sharing his insight with his colleagues when one of the other developers had
another insight. The clarity of seeing the model organized by 
KNOWLEDGE LEVEL
had let her spot
what had been bothering 
her
the previous day. Two distinct concepts were being combined in the
same object. She had heard it in the language used on the previous day but hadn't put her finger
on it:
An 
Employee Type
is assigned to either 
Retirement Plan
or either payroll.
But that was 
not
really a statement in the 
UBIQUITOUS LANGUAGE
. There was no "payroll" in the
model. They had spoken in the language they 
wanted
, rather than the one they had. The concept
of payroll was implicit in the model, lumped together with 
Employee Type
. It hadn't been so
obvious before the 
KNOWLEDGE LEVEL
was separated out, and the very elements in that key phrase
all appeared in the same level together . . . except one.
Based on this insight, she refactored again to a model that does support that statement.
The need for user control of the rules for associating objects drove the team to a model that had
an implicit 
KNOWLEDGE LEVEL
.

---