PROSAGA码农传奇-策略引擎-规范和政策之间的区别？

我正在阅读Eric Evans撰写的精彩著作《域驱动设计》。Eric在他的书中描述了两个不同的概念：规范模式和策略。这是规范的示例：
<pre><code>public interface ProjectSpecification {
 public boolean isSatisfiedBy(Project p);
}

public class ProjectIsOverdueSpecification implements ProjectSpecification {
  public boolean isSatisfiedBy(Project p) { … }
}

//client:
if {
 (projectIsOverdueSpecification.isSatisfiedBy(theCurrentProject) { … }
}
</code></pre>这是一个策略示例：
<pre><code>public class CargoBooking {

private OverBookingPolicy overBookingPolicy = new OverBookingPolicy();

public int makeBooking(Cargo cargo, Voyage voyage) {
    if (!overbookingPolicy.isAllowed(cargo, voyage)) 
      return –1;
    int confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
  }
}

public OverBookingPolicy {
 public boolean isAllowed(Cargo cargo, Voyage voyage) {
 return (cargo.size() + voyage.bookedCargoSize()) <= (voyage.capacity() * 1.1);
 }
}
</code></pre>我知道政策实际上是一项战略，但是在以上两个示例中绝对没有区别。所以我现在的问题是：这两种模式之间有什么区别？两种模式都使业务规则明确，为什么我们要区分这两种模式？对我来说，这都是谓词。

SPECIFICATION背后的主要思想是谓词，这通常意味着对其使用逻辑运算符

规范是对既有形式主义的改编（Eric Evans DDD，第274页）

例如，我们可以说该框为红色，即满足某些RedSpecification。我们可以声明一些GreenSpecification，甚至是复合RedOrGreenSpecification。如果我们有一些支持规范逻辑操作的高级框架，它可能像

```
BoxSpecification redBoxSpec = BoxSpecification.forColor(BoxColor.RED);
BoxSpecification greenBoxSpec = BoxSpecification.forColor(BoxColor.GREEN);
BoxSpecification redOrGreenBoxSpec = redBoxSpec.or(greenBoxSpec);
那么我们可以使用规范来查询某个存储库中的所有红色/绿色框：

Collection<Box> boxes = boxRepository.findAll(redOrGreenBoxSpec);
```

至于策略-这是策略模式的一种变体，但其主要目的是封装业务规则为某种声明形式。

从技术上讲-策略并不一定总是直接实现-在第一阶段它可以是一个单独的类（如蓝皮书的第一章所示），但以后可以轻松扩展

策略是设计模式的另一种名称，称为策略。策略通常是由于需要替换不同的规则而产生的，据我们所知，此处并不需要。但是我们试图捕获的概念确实符合策略的含义，这在域驱动设计中同样重要

例如，我们在1月份用黄色框包装礼物，在2月用红色框包装礼物

```
public class Box{
  public BoxColor getColor(){}
  public void recolor(BoxColor color){} 
}

public class BoxFactory{
    public Box createDefaultBox(SomeDate date){
         NewBoxPolicy boxPolicy = PolicyRegistry.getNewBoxPolicyForDate(date);
         Box box = new Box();
         boxPolicy.prepareBox(box);
         return box;
   }
}
public interface NewBoxPolicy{
   void prepareBox(Box box);
}
public class FebruaryNewBoxPolicy implements NewBoxPolicy{
    public void prepareBox(Box box) { box.recolor(BoxColor.RED}; }
}
public class JanuaryNewBoxPolicy implements NewBoxPolicy{
    public void prepareBox(Box box) { box.recolor(BoxColor.YELLOW}; }
}
public class PolicyRegistry{
   public static NewBoxPolicy getNewBoxPolicyForDate(SomeDate date){
      switch (date.month()){
         case SomeMonth.JANUARY: return JANUARY_NEW_BOX_POLICY;
         case SomeMonth.FEBRUARY: return FEBRUARY_NEW_BOX_POLICY;
         default: throw new AssertionError();
      }
}
```

重要的是要了解POLICY可以封装动作，而SPECIFICATION仅描述对象的属性（这些属性可以满足或不满足业务要求）。当然，某些验证策略可以使用规范来检查是否满足要求。

因此，您的项目中可以有许多不同的SPECIFICATION实例，它们可以从业务角度描述有效对象和无效对象。实际上，规范根本没有任何意义：例如，如果您有一个产品搜索站点，则用户可以指定一个搜索名称为“ XBOX”的产品的请求，但使用供应商名称为“ Sony”的产品（如果仅知道特定供应商可以生产您的模型中未捕获的特定产品。

POLICY的重要方面是其意图是封装实际的业务规则（因此代码不会分散在项目的不同部分），因此，当规则更改时，您可以轻松地找到相应的类。因此，您的项目中可以有许多规格，但数量可管理，并且易于查找和更改。

PS请注意，本文只是一个示例，而不是过度设计的许可，当然，您应该使用最简单的设计，这是常识。