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

part of the input parameters in a FACTORY reconstituting a stored object.
1.
A 
FACTORY
 reconstituting an object will handle violation of an invariant differently
. During
creation of a new object, a FACTORY should simply balk when an invariant isn't met, but a
more flexible response may be necessary in reconstitution. If an object already exists
somewhere in the system (such as in the database), this fact cannot be ignored. Yet we also
can't ignore the rule violation. There has to be some strategy for repairing such
inconsistencies, which can make reconstitution more challenging than the creation of new
objects.
2.
Figures 6.16 and 6.17 (on the next page) show two kinds of reconstitution. Object-mapping
technologies may provide some or all of these services in the case of database reconstitution,
which is convenient. Whenever there is exposed complexity in reconstituting an object from
another medium, the 
FACTORY
is a good option.
Figure 6.16. Reconstituting an 
ENTITY
 retrieved from a relational

---

database
Figure 6.17. Reconstituting an 
ENTITY
 transmitted as XML
To sum up, the access points for creation of instances must be identified, and their scope must be
defined explicitly. They may simply be constructors, but often there is a need for a more abstract
or elaborate instance creation mechanism. This need introduces new constructs into the design:
FACTORIES
. F
ACTORIES
usually do not express any part of the model, yet they are a part of the
domain design that helps keep the model-expressing objects sharp.
A 
FACTORY
encapsulates the life cycle transitions of creation and reconstitution. Another transition
that exposes technical complexity that can swamp the domain design is the transition to and from
storage. This transition is the responsibility of another domain design construct, the 
REPOSITORY
.
[ Team LiB ]

---

[ Team LiB ]