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

Sticking with M
ODEL
-D
RIVEN
 D
ESIGN
 When Mixing Paradigms
Rules engines will serve as an example of a technology sometimes mixed into an object-oriented
application development project. A knowledge-rich domain model probably contains explicit rules,
yet the object paradigm lacks specific semantics for stating rules and their interactions. Although
rules can be modeled as objects, and often are successfully, object encapsulation makes it
awkward to apply global rules that cross the whole system. Rules engine technology is appealing
because it promises to provide a more natural and declarative way to define rules, effectively
allowing the rules paradigm to be mixed into the object paradigm. The logic paradigm is well
developed and powerful, and it seems like a good complement to the strengths and weaknesses of
objects.
But people don't always get what they hope for out of rules engines. Some products just don't
work very well. Some lack a seamless view that can show the relatedness of model concepts that
run between the two implementation environments. One common outcome is an application
fractured in two: a static data storage system using objects, and an ad hoc rules processing
application that has lost almost all connection with the object model.
It is important to continue to think in terms of models while working with rules. The team has to
find a single model that can work with both implementation paradigms. This is not easy, but it
should be possible if the rules engine allows expressive implementation. Otherwise, the data and
the rules become unconnected. The rules in the engine end up more like little programs than
conceptual rules in the domain model. With tight, clear relationships between the rules and the
objects, the meaning of both pieces is retained.
Without a seamless environment, it falls on the developers to distill a model made up of clear,
fundamental concepts to hold the whole design together.

---

The most effective tool for holding the parts together is a robust 
UBIQUITOUS LANGUAGE
that
underlies the whole heterogeneous model. Consistently applying names in the two environments
and exercising those names in the 
UBIQUITOUS LANGUAGE
can help bridge the gap.
This is a topic that deserves a book of its own. The goal of this section is merely to show that it
isn't necessary to give up 
MODEL-DRIVEN DESIGN
, and that it is worth the effort to keep it.
Although a 
MODEL-DRIVEN DESIGN
does not have to be object oriented, it 
does
depend on having an
expressive implementation of the model constructs, be they objects, rules, or workflows. If the
available tool does not facilitate that expressiveness, reconsider the choice of tools. An
unexpressive implementation negates the advantage of the extra paradigm.
Here are four rules of thumb for mixing nonobject elements into a predominantly object-oriented
system:
Don't fight the implementation paradigm
. There's always another way to think about a
domain. Find model concepts that fit the paradigm.
Lean on the ubiquitous language
. Even when there is no rigorous connection between tools,
very consistent use of language can keep parts of the design from diverging.
Don't get hung up on UML
. Sometimes the fixation on a tool, such as UML diagramming,
leads people to distort the model to make it fit what can easily be drawn. For example, UML
does have some features for representing constraints, but they are not always sufficient.
Some other style of drawing (perhaps conventional for the other paradigm), or simple English
descriptions, are better than tortuous adaptation of a drawing style intended for a certain
view of objects.
Be skeptical
. Is the tool really pulling its weight? Just because you have some rules, that
doesn't necessarily mean you need the overhead of a rules engine. Rules can be expressed
as objects, perhaps a little less neatly; multiple paradigms complicate matters enormously.
Before taking on the burden of mixed paradigms, the options within the dominant paradigm should
be exhausted. Even though some domain concepts don't present themselves as obvious objects,
they often can be modeled within the paradigm. Chapter 9 will discuss the modeling of
unconventional types of concepts using object technology
The relational paradigm is a special case of paradigm mixing. The most common nonobject
technology, the relational database is also more intimately related to the object model than other
components, because it acts as the persistent store of the data that makes up the objects
themselves. Storing object data in relational databases will be discussed in Chapter 6, along with
the many other challenges of the object life cycle.
[ Team LiB ]

---

[ Team LiB ]