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

Fowler Terminology
POSA Terminology
[2]
Knowledge Level
Meta Level
Operations Level
Base Level
[2]
POSA is short for 
Pattern-Oriented Software Architecture
, by Buschmann et al. 1996.
Comparing the terminology of 
KNOWLEDGE LEVEL
and 
REFLECTION
Just to be clear, the reflection tools of the programming language are 
not
for use in implementing
the 
KNOWLEDGE LEVEL
of a domain model. Those meta-objects describe the structure and behavior
of the language constructs themselves. Instead, the 
KNOWLEDGE LEVEL
must be built of ordinary
objects.
The 
KNOWLEDGE LEVEL
provides two useful distinctions. First, it focuses on the application domain,
in contrast to familiar uses 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.
Therefore:
Create a distinct set of objects that can be used to describe and constrain the structure
and behavior of the basic model. Keep these concerns separate as two "levels," one
very concrete, the other reflecting rules and knowledge that a user or superuser is able
to customize.
Like all powerful ideas, 
REFLECTION
and 
KNOWLEDGE LEVELS
can be intoxicating. This pattern should
be used sparingly. It can unravel complexity by freeing operations objects from the need to be
jacks-of-all-trades, but the indirection it introduces does add some of that obscurity back in. If the
KNOWLEDGE LEVEL
becomes complex, the system's behavior becomes hard to understand for
developers and users alike. The users (or superuser) who configure it will end up needing the skills
of a programmer—and a meta-level programmer at that. If they make mistakes, the application
will behave incorrectly.
Also, the basic problems of data migration don't completely disappear. When a structure in the
KNOWLEDGE LEVEL
is changed, existing operations-level objects have to be dealt with. It may be
possible for old and new to coexist, but one way or another, careful analysis is needed.
All of these issues put a major burden on the designer of a 
KNOWLEDGE LEVEL
. The design has to be
robust enough to handle not only the scenarios presented in development, but also any scenario
for which a user could configure the software in the future. Applied judiciously, to the points where

---

customization is crucial and would otherwise distort the design, 
KNOWLEDGE LEVELS
can solve
problems that are very hard to handle any other way.