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

Retirement Plan
or either payroll.
Employees
are constrained by the 
Employee Type
.
Access to edit the 
Employee Type
object will be restricted to a "superuser," who will make
changes only when company policy changes. An ordinary user in the personnel department can
change 
Employees
or point them at a different 
Employee Type
.
This model satisfies the requirements. The developers sense an implicit concept or two, but it is
just a nagging feeling at the moment. They don't have any solid ideas to pursue, so they call it a
day.
A static model can cause problems. But problems can be just as bad with a fully flexible system
that allows any possible relationship to be presented. Such a system would be inconvenient to use
and wouldn't allow the organization's own rules to be enforced.
Fully customizing software for each organization is not practical because, even if each organization
could pay for custom software, the organizational structure will likely change frequently.
So such software must provide options to allow the 
user
to configure it to reflect the current
structure of the organization. The trouble is that adding such options to the model objects makes
them unwieldy. The more flexibility you add, the more complex it all becomes.
In an application in which the roles and relationships between 
ENTITIES
 vary in different
situations, complexity can explode. Neither fully general models nor highly customized
ones serve the users' needs. Objects end up with references to other types to cover a
variety of cases, or with attributes that are used in different ways in different
situations. Classes that have the same data and behavior may multiply just to
accommodate different assembly rules.
Nestled into our model is another model that is 
about
our model. A 
KNOWLEDGE LEVEL
separates
that self-defining aspect of the model and makes its constraints explicit.
K
NOWLEDGE LEVEL
is an application to the domain layer of the 
REFLECTION
pattern, used in many
software architectures and technical infrastructures and described well in Buschmann et al. 1996.
R
EFLECTION
accommodates changing needs by making the software "self-aware," and making
selected aspects of its structure and behavior accessible for adaptation and change. This is done
by splitting the software into a "base level," which carries the operational responsibility for the
application, and a "meta level," which represents knowledge of the structure and behavior of the
software.
Significantly, the pattern is not called a knowledge "layer." As much as it resembles layering,
REFLECTION
involves mutual dependencies running in both directions.
Java has some minimal built-in 
REFLECTION
in the form of protocols for interrogating a class for its

---

methods and so forth. Such mechanisms allow a program to ask questions about its own design.
CORBA has somewhat more extensive but similar 
REFLECTION
protocols. Some persistence
technologies extend the richness of that self-description to support partially automated mapping
between database tables and objects. There are other technical examples. This pattern can also be
applied within the domain layer.
The 
KNOWLEDGE LEVEL
provides two useful distinctions. First, it focuses on the application domain,
in contrast to familiar applications of 
REFLECTION
. Second, it does not strive for full generality. Just
as a 
SPECIFICATION
can be more useful than a general predicate, a very specialized set of
constraints on a set of objects and their relationships can be more useful than a generalized
framework. The 
KNOWLEDGE LEVEL
is simpler and can communicate the specific intent of the
designer.