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

1.
The database was designed for another system.
2.
The database is designed for this system but serves in roles other than object store.
3.
When the database schema is being created specifically as a store for the objects, it is worth
accepting some model limitations in order to keep the mapping very simple. Without other
demands on schema design, the database can be structured to make aggregate integrity safer and
more efficient as updates are made. Technically, the relational table design does not have to
reflect the domain model. Mapping tools are sophisticated enough to bridge significant differences.
The trouble is, multiple overlapping models are just too complicated. Many of the same arguments
presented for 
MODEL-DRIVEN DESIGN
—avoiding separate analysis and design models—apply to this
mismatch. This does entail some sacrifice in the richness of the object model, and sometimes
compromises have to be made in the database design (such as selective denormalization), but to
do otherwise is to risk losing the tight coupling of model and implementation. This approach
doesn't require a simplistic one-object/one-table mapping. Depending on the power of the
mapping tool, some aggregation or composition of objects may be possible. But it is crucial that
the mappings be transparent, easily understandable by inspecting the code or reading entries in
the mapping tool.
When the database is being viewed as an object store, don't let the data model and the
object model diverge far, regardless of the powers of the mapping tools. Sacrifice some
richness of object relationships to keep close to the relational model. Compromise some
formal relational standards, such as normalization, if it helps simplify the object mapping.
Processes outside the object system should not access such an object store. They could
violate the invariants enforced by the objects. Also, their access will lock in the data model so
that it is hard to change when the objects are refactored.
On the other hand, there are many cases in which the data comes from a legacy or external
system that was never intended as a store of objects. In this situation, there are, in reality, two
domain models coexisting in the same system. Chapter 14, "Maintaining Model Integrity," deals
with this issue in depth. It may make sense to conform to the model implicit in the other system,
or it may be better to make the model completely distinct.
Another reason for exceptions is performance. Quirky design changes may have to be introduced

---

to solve execution speed problems.
But for the important common case of a relational database acting as the persistent form of an
object-oriented domain, simple directness is best. A table row should contain an object, perhaps
along with subsidiaries in an 
AGGREGATE
. A foreign key in the table should translate to a reference
to another 
ENTITY
object. The necessity of sometimes deviating from this simple directness should
not lead to total abandonment of the principle of simple mappings.
The 
UBIQUITOUS LANGUAGE
can help tie the object and relational components together to a single
model. The names and associations of elements in the objects should correspond meticulously to
those of the relational tables. Although the power of some mapping tools may make this seem
unnecessary, subtle differences in relationships will cause a lot of confusion.
The tradition of refactoring that has increasingly taken hold in the object world has not really
affected relational database design much. What's more, serious data migration issues discourage
frequent change. This may create a drag on the refactoring of the object model, but if the object
model and the database model start to diverge, transparency can be lost quickly.
Finally, there are some reasons to go with a schema that is quite distinct from the object model,
even when the database is being created specifically for your system. The database may also be
used by other software that will not instantiate objects. The database may require little change,
even while the behavior of the objects changes or evolves rapidly. Cutting the two loose from each
other is a seductive path. It is often taken unintentionally, when the team fails to keep the
database current with the model. If the separation is chosen consciously, it can result in a clean
database schema—not an awkward one full of compromises conforming to last year's object
model.
[ Team LiB ]

---

[ Team LiB ]