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

Strategy (A.K.A.Policy)
Define a family of algorithms, encapsulate each one, and make them interchangeable.
S
TRATEGY
lets the algorithm vary independently from clients that use it. [Gamma et al. 1995]
Domain models contain processes that are not technically motivated but actually
meaningful in the problem domain. When alternative processes must be provided, the
complexity of choosing the appropriate process combines with the complexity of the
multiple processes themselves, and things get out of hand.
When we model processes, we often realize that there is more than one legitimate way of doing
them. As we start to describe these options, our definition of the process becomes clumsy and
complicated. The actual behavioral alternatives we are choosing between are obscured as they are
mixed in with the rest of the behavior.
We would like to separate this variation from the main concept of the process. Then we would be
able to see both the main process and the options more clearly. The 
STRATEGY
pattern, already
well established in the software design community, addresses this very issue, though the focus is
technical. Here it is being applied as a concept in a model and reflected in the code implementation
of that model. There is the same need to decouple the highly variable part of the process from the
more stable part.
Therefore:
Factor the varying part of a process into a separate "strategy" object in the model.
Factor apart a rule and the behavior it governs. Implement the rule or substitutable
process following the 
STRATEGY
 design pattern. Multiple versions of the strategy object
represent different ways the process can be done.
Whereas the conventional view of 
STRATEGY
as a design pattern focuses on the ability to substitute
different algorithms, its use as a domain pattern focuses on its ability to express a concept, usually
a process or a policy rule.

---