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

In an object-oriented program, UI, database, and other support code often gets written
directly into the business objects. Additional business logic is embedded in the
behavior of UI
widgets and data-base scripts. This happens because it is the easiest
way to make things work, in the short run.
When the domain-related code is diffused through such a large amount of other code, it
becomes extremely difficult to see and to reason about. Superficial changes to the UI
can actually change business logic. To change a business rule may require meticulous
tracing of UI
code, database code, or other program elements. Implementing coherent,
model-driven objects becomes impractical. Automated testing is awkward. With all the
technologies and logic involved in each activity, a program must be kept very simple or
it becomes impossible to understand.
Creating programs that can handle very complex tasks calls for separation of concerns, allowing
concentration on different parts of the design in isolation. At the same time, the intricate

---

interactions within the system must be maintained in spite of the separation.
There are all sorts of ways a software system might be divided, but through experience and
convention, the industry has converged on 
LAYERED ARCHITECTURES
, and specifically a few fairly
standard layers. The metaphor of layering is so widely used that it feels intuitive to most
developers. Many good discussions of layering are available in the literature, sometimes in the
format of a pattern (as in Buschmann et al. 1996, pp. 31–51). The essential principle is that any
element of a layer depends only on other elements in the same layer or on elements of the layers
"beneath" it. Communication upward must pass through some indirect mechanism, which I'll
discuss a little later.
The value of layers is that each specializes in a particular aspect of a computer program. This
specialization allows more cohesive designs of each aspect, and it makes these designs much
easier to interpret. Of course, it is vital to choose layers that isolate the most important cohesive
design aspects. Again, experience and convention have led to some convergence. Although there
are many variations, most successful architectures use some version of these four conceptual
layers: