Excerpted from DomainDrivenDesignBook
Problem: 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.
Solution: 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.
See also: DesignPatternsStrategy is mentioned on: Policy | MessagesByTopic | DAOVersusRepository | PatternForDatabaseDeadlocks | HowLongDoYouCacheObjectValues | DomainLayerAccessFromJSPsAndHandlers | StreamlinedObjectModeling | TerminologyQuestionOnValueObjectsAndEntities