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

Modeling Paradigms and Tool Support
To make a 
MODEL-DRIVEN DESIGN
pay off, the correspondence must be literal, exact within bounds
of human error. To make such a close correspondence of model and design possible, it is almost
essential to work within a modeling paradigm supported by software tools that allow you to create
direct analogs to the concepts in the model.
Figure 3.1.
Object-oriented programming is powerful because it is based on a modeling paradigm, and it
provides implementations of the model constructs. As far as the programmer is concerned, objects
really exist in memory, they have associations with other objects, they are organized into classes,
and they provide behavior available by messaging. Although many developers benefit from just
applying the technical capabilities of objects to organize program code, the real breakthrough of
object design comes when the code expresses the concepts of a model. Java and many other tools
allow the creation of objects and relationships directly analogous to conceptual object models.
Although it has never reached the mass usage that object-oriented languages have, the Prolog
language is a natural fit for 
MODEL-DRIVEN DESIGN
. In this case, the paradigm is logic, and the
model is a set of logical rules and facts they operate on.
M
ODEL-DRIVEN DESIGN
has limited applicability using languages such as C, because there is no
modeling paradigm that corresponds to a purely 
procedural
language. Those languages are
procedural in the sense that the programmer tells the computer a series of steps to follow.
Although the programmer may be thinking about the concepts of the domain, the program itself is
a series of technical manipulations of data. The result may be useful, but the program doesn't
capture much of the meaning. Procedural languages often support complex data types that begin
to correspond to more natural conceptions of the domain, but these complex types are only
organized data, and they don't capture the active aspects of the domain. The result is that
software written in procedural languages has complicated functions linked together based on

---

anticipated paths of execution, rather than by conceptual connections in the domain model.
Before I ever heard of object-oriented programming, I wrote fortran programs to solve
mathematical models, which is just the sort of domain in which fortran excels. Mathematical
functions are the main conceptual component of such a model and can be cleanly expressed in
fortran. Even so, there is no way to capture higher level meaning beyond the functions. Most non-
mathematical domains don't lend themselves to 
MODEL-DRIVEN DESIGN
in procedural languages
because the domains are not conceptualized as math functions or as steps in a procedure.
Object-oriented design, the paradigm that currently dominates the majority of ambitious projects,
is the approach used primarily in this book.