《领域模型》——设计模式应用于模型

　　在设计模式中，有些模式可以用作领域模型，但是这些使用的时候需要变换一下重点。设计模式中把相关设计元素归为一类，这些元素能够解决在各种上下文中经常遇到的问题，这些模式的动机以及模式本身都是从纯技术角度描述，但这些元素中的一部分在更广泛的领域和设计上下文中也使用，因为这些元素对应的基本概念在很多领域中都会出现。

模式：Strategy（策略模式、也称为policy）

　　Strategy——定义了一组算法，将每个算法封装起来，并使他可以互换。Strategy允许算法独立与使用他的客户而变化。

　　领域模型包含一些并非用于解决技术问题的过程，将他们包含进来是因为他们对处理问题领域具有价值。当必须从多个过程中进行选择时，选择的复杂性再加上多个过程本身的复杂性会使局面失去控制。当对过程进行建模时，我们经常会发现不止一种合理的建模方式，如果都写到过程定义中，就会变得臃肿而复杂，行为描述也会因为混杂在其他行为中而模糊不清，所以希望把这些选择从过程的主体概念中，这样技能看清主体概念也能看清选择，Strategy就是为了解决这个问题的，虽然Strategy侧重与技术方面，但在这里我们把他当成模型中的一个概念使用，同样把过程中极易发生变化的部份与稳定的部分分离。

　　因此易变化的部分提取到模型的“策略”对象。将规则与他所控制的行为区分开，按照Strategy来实现规则或可替换的过程。策略对象的多个版本表示完成过程的不同方式。

示例:路线查找（Route-Finding）策略

把一个Route Specification（路线规格）传递给Routing Service(路线服务)，Routing Service的工作是构造一个满足Specification的详细的Itinerary。这个Service是一个优化引擎，可以通过调节它来查找最快的路线或最便宜的路线。 

　　仔细观察路线代码就会发现，每个计算中都有条件判断，导出都是判断最快还是最便宜的逻辑，当为了做出更精细的航线选择而把新标准添加进来时，麻烦会更多。

　　解决方法是把这些起调节作用的参数分离到Strategy中。使之明确的标识出来，并作为参数传递给Routing Service。现在Routing Service就可以用一种完全相同的、无需条件判断的方法来处理所有请求了，它按照Leg Magnitude Policy（航段规模策略）的计算，找出一些里规模较小的Leg。

　　这种设计具有设计模式中的Strategy模式的优点，现在可以通过安装适当的Leg Magnitude Policy来控制和扩展 Routing Service的行为。如图中显示的只是最明显的2种Strategy。可能还会有一些在速度和价钱之前权衡的策略，也可以加入其他因素，例如在预定货物时邮件选择公司自己的运输系统，而不是外包其他运算公司，当然不用策略模式也能实现这种扩展，但这样还是要在Routing Service内部去修改，这就会使接口变得越来越臃肿，接口可以令Routing Service更清楚且容易测试。

　　现在，领域中的一个只管重要的规则明确的显示了出来，也就是构建在路线时选择Leg的基本规则。他传递了这样一个知识：路线选择的基础是航段的一个特定属性，这个属性最后可鬼节为一个数字。这样我们可以在领域语言中用一句简单的话来定义Routing Service的行为：Routing Service根据所选定的策略来选择航段总规模最小的路线。

　　我们在领域中使用技术设计模式时，必须认识到另一种动机，也是它的另一层含义，当所使用的策略对应与某种实际业务的策略时，模式就不再仅仅是一种游泳的实现技术了。