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

Nonobjects in an Object World

---

A domain model does not have to be an object model. There are 
MODEL-DRIVEN DESIGNS
implemented in Prolog, for example, with a model made up of logical rules and facts. Model
paradigms have been conceived to address certain ways people like to think about domains. Then
the models of those domains are shaped by the paradigm. The result is a model that conforms to
the paradigm so that it can be effectively implemented in the tools that support that modeling
style.
Whatever the dominant model paradigm may be on a project, there are bound to be parts of the
domain that would be much easier to express in some other paradigm. When there are just a few
anomalous elements of a domain that otherwise works well in a paradigm, developers can live with
a few awkward objects in an otherwise consistent model. (Or, on the other extreme, if the greater
part of the problem domain is more naturally expressed in a particular other paradigm, it may
make sense to switch paradigms altogether and choose a different implementation platform.) But
when major parts of the domain seem to belong to different paradigms, it is intellectually
appealing to model each part in a paradigm that fits, using a mixture of tool sets to support
implementation. When the interdependence is small, a subsystem in the other paradigm can be
encapsulated, such as a complex math calculation that simply needs to be called by an object.
Other times the different aspects are more intertwined, such as when the interaction of the objects
depends on some mathematical relationships.
This is what motivates the integration into object systems of such nonobject components as
business rules engines and workflow engines. Mixing paradigms allows developers to model
particular concepts in the style that fits best. Furthermore, most systems must use some
nonobject technical infrastructure, most commonly relational databases. But making a coherent
model that spans paradigms is hard, and making the supporting tools coexist is complicated. When
developers can't clearly see a coherent model embodied in the software, 
MODEL-DRIVEN DESIGN
can
go out the window, even as this mixture increases the need for it.