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

Knowledge Level
[A KNOWLEDGE LEVEL is] a group of objects that describes how another group of objects
should behave. [Martin Fowler, "Accountability," www.martinfowler.com]
K
NOWLEDGE LEVEL
untangles things when we need to let some part of the model itself be plastic in
the user's hands yet constrained by a broader set of rules. It addresses requirements for software
with configurable behavior, in which the roles and relationships among 
ENTITIES
must be changed
at installation or even at runtime.
In 
Analysis Patterns
(Fowler 1996, pp. 24–27), the pattern emerges from a discussion of modeling
accountability within organizations, and it is later applied to posting rules in accounting. Although
the pattern appears in several chapters, it doesn't have a chapter of its own because it is different
from most patterns in the book. Rather than modeling a domain, as the other analysis patterns
do, 
KNOWLEDGE LEVEL
structures a model.
To see the problem concretely, consider models of "accountability." Organizations are made up of
people and smaller organizations, and define the roles they play and the relationships between
them. The rules governing those roles and relationships vary greatly for different organizations. At
one company, a "department" might be headed by a "Director" who reports to a "Vice President."
In another company, a "module" is headed by a "Manager" who reports to a "Senior Manager."
Then there are "matrix" organizations, in which each person reports to different managers for
different purposes.
A typical application would make some assumptions. When those didn't fit, users would start to
use data-entry fields in a different way than they were intended. Any behavior the application had
would misfire, as the semantics were changed by the users. Users would develop workarounds for
the behavior, or would get the higher level features of the application shut off. They would be
forced to learn complicated mappings between what they did in their jobs and the way the
software works. They would never be served well.
When the system had to be changed or replaced, developers would discover (sooner or later) that
the meanings of the features were not what they seemed. They might mean very different things
in different user communities or in different situations. Changing anything without breaking these
overlaid usages would be daunting. Data migration to a more tailored system would require
understanding and coding for all those quirks.