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

Designing the Interface
When designing the method signature of a 
FACTORY
, whether standalone or 
FACTORY METHOD
, keep
in mind these two points.
Each operation must be atomic
. You have to pass in everything needed to create a complete
product in a single interaction with the 
FACTORY
. You also have to decide what will happen if
creation fails, in the event that some invariant isn't satisfied. You could throw an exception or
just return a null. To be consistent, consider adopting a coding standard for failures in
FACTORIES
.
The 
FACTORY
 will be coupled to its arguments
. If you are not careful in your selection of input
parameters, you can create a rat's nest of dependencies. The degree of coupling will depend
on what you do with the argument. If it is simply plugged into the product, you've created a
modest dependency. If you are picking parts out of the argument to use in the construction,
the coupling gets tighter.
The safest parameters are those from a lower design layer. Even within a layer, there tend to be
natural strata with more basic objects that are used by higher level objects. (Such layering will be
discussed in different ways in Chapter 10, "Supple Design," and again in Chapter 16, "Large-Scale
Structure.")
Another good choice of parameter is an object that is closely related to the product in the model,
so that no new dependency is being added. In the earlier example of a 
Purchase Order Item
,
the 
FACTORY METHOD
takes a 
Catalog Part
as an argument, which is an essential association for
the 
Item
. This adds a direct dependency between the 
Purchase Order
class and the 
Part
. But
these three objects form a close conceptual group. The