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

Partition a conceptually 
COHESIVE MECHANISM
 into a separate lightweight framework.
Particularly watch for formalisms or well-documented categories of algorithms. Expose
the capabilities of the framework with an 
INTENTION-REVEALING INTERFACE
. Now the other
elements of the domain can focus on expressing the problem ("what"), delegating the
intricacies of the solution ("how") to the framework.
These separated mechanisms are then placed in their supporting roles, leaving a smaller, more
expressive 
CORE DOMAIN
that uses the mechanism through the interface in a more declarative
style.
Recognizing a standard algorithm or formalism moves some of the complexity of the design into a
studied set of concepts. With such a guide, we can implement a solution with confidence and little
trial and error. We can count on other developers knowing about it or at least being able to look it
up. This is similar to the benefits of a published 
GENERIC SUBDOMAIN
model, but a documented
algorithm or formal computation may be found more often because this level of computer science
has been studied more. Still, more often than not you will have to create something new. Make it
narrowly focused on the computation and avoid mixing in the expressive domain model. There is a
separation of responsibilities: The model of the 
CORE DOMAIN
or a 
GENERIC SUBDOMAIN
formulates a
fact, rule, or problem. A 
COHESIVE MECHANISM
resolves the rule or completes the computation as
specified by the model.
Example
A Mechanism in an Organization Chart
I went through this process on a project that needed a fairly elaborate model of an organization
chart. This model represented the fact that one person worked for another, and in which branches
of the organization, and it provided an interface by which relevant questions might be asked and
answered. Because most of these questions were along the lines of "Who, in this chain of
command, has authority to approve this?" or "Who, in this department, is capable of handling an

---

issue like this?" the team realized that most of the complexity involved traversing specific
branches of the organizational tree, searching for specific people or relationships. This is exactly
the kind of problem solved by the well-developed formalism of a 
graph
, a set of nodes connected
by arcs (called 
edges
) and the rules and algorithms needed to traverse the graph.
A subcontractor implemented a graph traversal framework as a 
COHESIVE MECHANISM
. This
framework used standard graph terminology and algorithms familiar to most computer scientists
and abundantly documented in textbooks. By no means did he implement a fully general graph. It
was a subset of that conceptual framework that covered the features needed for our organization
model. And with an 
INTENTION-REVEALING INTERFACE
, the means by which the answers are obtained
are not a primary concern.
Now the organization model could simply state, using standard graph terminology, that each
person is a node, and that each relationship between people is an edge (arc) connecting those
nodes. After that, presumably, mechanisms within the graph framework could find the relationship
between any two people.
If this mechanism had been incorporated into the domain model, it would have cost us in two
ways. The model would have been coupled to a particular method of solving the problem, limiting
future options. More important, the model of an organization would have been greatly complicated
and muddied. Keeping mechanism and model separate allowed a declarative style of describing
organizations that was much clearer. And the intricate code for graph manipulation was isolated in
a purely mechanistic framework, based on proven algorithms, that could be maintained and unit-
tested in isolation.
Another example of a 
COHESIVE MECHANISM
would be a framework for constructing 
SPECIFICATION
objects and supporting the basic comparison and combination operations expected of them. By
employing such a framework, the 
CORE DOMAIN
and 
GENERIC SUBDOMAINS
can declare their
SPECIFICATIONS
in the clear, easily understood language described in that pattern (see Chapter 10).
The intricate operations involved in carrying out the comparisons and combinations can be left to
the framework.