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

E
NTITY
 F
ACTORIES
 Versus V
ALUE
 O
BJECT
 F
ACTORIES
ENTITY FACTORIES
differ from 
VALUE OBJECT FACTORIES
in two ways. V
ALUE OBJECTS
are Immutable;
the product comes out complete in its final form. So the 
FACTORY
operations have to allow for a full
description of the product. E
NTITY FACTORIES
tend to take just the essential attributes required to
make a valid 
AGGREGATE
. Details can be added later if they are not required by an invariant.
Then there are the issues involved in assigning identity to an 
ENTITY
—irrelevant to a 
VALUE OBJECT
.
As pointed out in Chapter 5, an identifier can either be assigned automatically by the program or
supplied from the outside, typically by the user. If a customer's identity is to be tracked by the
telephone number, then that telephone number must obviously be passed in as an argument to
the 
FACTORY
. When the program is assigning an identifier, the 
FACTORY
is a good place to control it.
Although the actual generation of a unique tracking ID is typically done by a database "sequence"
or other infrastructure mechanism, the 
FACTORY
knows what to ask for and where to put it.
Reconstituting Stored Objects
Up to this point, the 
FACTORY
has played its part in the very beginning of an object's life cycle. At
some point, most objects get stored in databases or transmitted through a network, and few
current database technologies retain the object character of their contents. Most transmission
methods flatten an object into an even more limited presentation. Therefore, retrieval requires a
potentially complex process of reassembling the parts into a live object.
A 
FACTORY
used for reconstitution is very similar to one used for creation, with two major
differences.
An 
ENTITY FACTORY
 used for reconstitution does not assign a new tracking ID
. To do so would
lose the continuity with the object's previous incarnation. So identifying attributes must be