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

Partition a complex program into layers. Develop a design within each layer that is
cohesive and that depends only on the layers below. Follow standard architectural
patterns to provide loose coupling to the layers above. Concentrate all the code related
to the domain model in one layer and isolate it from the user interface, application, and
infrastructure code. The domain objects, free of the responsibility of displaying
themselves, storing themselves, managing application tasks, and so forth, can be

---

focused on expressing the domain model. This allows a model to evolve to be rich
enough and clear enough to capture essential business knowledge and put it to work.
Separating the domain layer from the infrastructure and user interface layers allows a much
cleaner design of each layer. Isolated layers are much less expensive to maintain, because they
tend to evolve at different rates and respond to different needs. The separation also helps with
deployment in a distributed system, by allowing different layers to be placed flexibly in different
servers or clients, in order to minimize communication overhead and improve performance (Fowler
1996).
Example
Partitioning Online Banking Functionality into Layers
An application provides various capabilities for maintaining bank accounts. One feature is funds
transfer, in which the user enters or chooses two account numbers and an amount of money and
then initiates a transfer.
To make this example manageable, I've omitted major technical features, most notably security.
The domain design is also oversimplified. (Realistic complexity would only increase the need for
layered architecture.) Furthermore, the particular infrastructure implied here is meant to be simple
and obvious to make the example clear—it is not a suggested design. The responsibilities of the
remaining functionality would be layered as shown in Figure 4.1.