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

Unless there is a real intention to distribute code on different servers, keep all the code
that implements a single conceptual object in the same 
MODULE
, if not the same object.
We could have come to the same conclusion by drawing on the old standard, "high cohesion/low
coupling." The connections between an "object" implementing the business logic and the one
responsible for database access are so extensive that the coupling is very high.
There are other pitfalls where framework design or just conventions of a company or project can
undermine 
MODEL-DRIVEN DESIGN
by obscuring the natural cohesion of the domain objects, but the
bottom line is the same. The restrictions, or just the large number of required packages, rules out
the use of other packaging schemes that are tailored to the needs of the domain model.
Use packaging to separate the domain layer from other code. Otherwise, leave as much

---

freedom as possible to the domain developers to package the domain objects in ways
that support their model and design choices.
One exception arises when code is generated based on a declarative design (discussed in Chapter
10). In that case, the developers do not need to read the code, and it is better to put it into a
separate package so that it is out of the way, not cluttering up the design elements developers
actually have to work with.
Modularity becomes more critical as the design gets bigger and more complex. This section
presents the basic considerations. Much of Part IV, "Strategic Design," provides approaches to
packaging and breaking down big models and designs, and ways to give people focal points to
guide understanding.
Each concept from the domain model should be reflected in an element of implementation. The
ENTITIES
, 
VALUE OBJECTS
, and their associations, along with a few domain 
SERVICES
and the
organizing 
MODULES
, are points of direct correspondence between the implementation and the
model. The objects, pointers, and retrieval mechanisms in the implementation must map to model
elements straightforwardly, obviously. If they do not, clean up the code, go back and change the
model, or both.
Resist the temptation to add anything to the domain objects that does not closely relate to the
concepts they represent. These design elements have their job to do: they express the model.
There are other domain-related responsibilities that must be carried out and other data that must
be managed in order to make the system work, but they don't belong in these objects. In Chapter
6, I will discuss some supporting objects that fulfill the technical responsibilities of the domain
layer, such as defining database searches and encapsulating complex object creation.
The four patterns in this chapter provide the building blocks for an object model. But 
MODEL-DRIVEN
DESIGN
does not necessarily mean forcing everything into an object mold. There are also other
model paradigms supported by tools, such as rules engines. Projects have to make pragmatic
trade-offs between them. These other tools and techniques are means to the end of a 
MODEL-
DRIVEN DESIGN
, not alternatives to it.
[ Team LiB ]

---

[ Team LiB ]