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

Purchase Order's
AGGREGATE
already
referenced the 
Part
, anyway. So giving control to the 
AGGREGATE
root and encapsulating the
AGGREGATE'S
internal structure is a good trade-off.
Use the abstract type of the arguments, not their concrete classes. The 
FACTORY
is coupled to the
concrete class of the products; it does not need to be coupled to concrete parameters also.
Where Does Invariant Logic Go?
A 
FACTORY
is responsible for ensuring that all invariants are met for the object or 
AGGREGATE
it
creates; yet you should always think twice before removing the rules applying to an object outside
that object. The 
FACTORY
can delegate invariant checking to the product, and this is often best.
But 
FACTORIES
have a special relationship with their products. They already know their product's
internal structure, and their entire reason for being involves the implementation of their product.
Under some circumstances, there are advantages to placing invariant logic in the 
FACTORY
and
reducing clutter in the product. This is especially appealing with 
AGGREGATE
rules (which span
many objects). It is especially 
unappealing
with 
FACTORY METHODS
attached to other domain
objects.

---

Although in principle invariants apply at the end of every operation, often the transformations
allowed to the object can never bring them into play. There might be a rule that applies to the
assignment of the identity attributes of an 
ENTITY
. But after creation that identity is immutable.
V
ALUE OBJECTS
are completely immutable. An object doesn't need to carry around logic that will
never be applied in its active lifetime. In such cases, the 
FACTORY
is a logical place to put
invariants, keeping the product simpler.