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

Figure 4.1. Objects carry out responsibilities consistent with their layer
and are more coupled to other objects in their layer.
Note that the domain layer, 
not the application layer
, is responsible for fundamental business
rules—in this case, the rule is "Every credit has a matching debit."
The application also makes no assumptions about the source of the transfer request. The program

---

presumably includes a UI with entry fields for account numbers and amounts and with buttons for
commands. But that user interface could be replaced by a wire request in XML without affecting
the application layer or any of the lower layers. This decoupling is important not because projects
frequently need to replace user interfaces with wire requests but because a clean separation of
concerns keeps the design of each layer easy to understand and maintain.
In fact, Figure 4.1 itself mildly illustrates the problem of not isolating the domain. Because
everything from the request to transaction control had to be included, the domain layer had to be
dumbed down to keep the overall interaction simple enough to follow. If we were focused on the
design of the isolated domain layer, we would have space on the page and in our heads for a
model that better represented the domain's rules, perhaps including ledgers, credit and debit
objects, or monetary transaction objects.
Relating the Layers
So far the discussion has focused on the separation of layers and the way in which that
partitioning improves the design of each aspect of the program, particularly the domain layer. But
of course, the layers have to be connected. To do this without losing the benefit of the separation
is the motivation behind a number of patterns.
Layers are meant to be loosely coupled, with design dependencies in only one direction. Upper
layers can use or manipulate elements of lower ones straightforwardly by calling their public
interfaces, holding references to them (at least temporarily), and generally using conventional
means of interaction. But when an object of a lower level needs to communicate upward (beyond
answering a direct query), we need another mechanism, drawing on architectural patterns for
relating layers such as callbacks or 
OBSERVERS
(Gamma et al. 1995).
The grandfather of patterns for connecting the UI to the application and domain layers is 
MODEL-
VIEW-CONTROLLER
(MVC). It was pioneered in the Smalltalk world back in the 1970s and has
inspired many of the UI architectures that followed. Fowler (2002) discusses this pattern and
several useful variations on the theme. Larman (1998) explores these concerns in the 
MODEL-VIEW
SEPARATION PATTERN
, and his 
APPLICATION COORDINATOR
is one approach to connecting the
application layer.
There are other styles of connecting the UI and the application. For our purposes, all approaches
are fine as long as they maintain the isolation of the domain layer, allowing domain objects to be
designed without simultaneously thinking about the user interface that might interact with them.
The infrastructure layer usually does not initiate action in the domain layer. Being "below" the
domain layer, it should have no specific knowledge of the domain it is serving. Indeed, such
technical capabilities are most often offered as 
SERVICES
. For example, if an application needs to
send an e-mail, some message-sending interface can be located in the infrastructure layer and the
application layer elements can request the transmission of the message. This decoupling gives
some extra versatility. The message-sending interface might be connected to an e-mail sender, a
fax sender, or whatever else is available. But the main benefit is simplifying the application layer,
keeping it narrowly focused on its job: knowing 
when
to send a message, but not burdened with
how
.
The application and domain layers call on the 
SERVICES
provided by the infrastructure layer. When
the scope of a 
SERVICE
has been well chosen and its interface well designed, the caller can remain
loosely coupled and uncomplicated by the elaborate behavior the 
SERVICE
interface encapsulates.
But not all infrastructure comes in the form of 
SERVICES
callable from the higher layers. Some
technical components are designed to directly support the basic functions of other layers (such as
providing an abstract base class for all domain objects) and provide the mechanisms for them to

---

relate (such as implementations of MVC and the like). Such an "architectural framework" has
much more impact on the design of the other parts of the program.