可插拔业务规则的设计

总结得不错，规则是属于业务方法。根据系统的重点特点，引入
Drools这些规则引擎是一个重量方案，规则的设计也相当抽象，不如直接和领域对象融合在一起分析容易。

我的观点：除非复杂到迫不得已，否则还是先从规格模式入手，以后重构到规则引擎上。

规约（Specification）模式

这篇文章里面有评论说：
Specification Pattern是一种基于重构已有实现的结果，是面向实现的，而且是面向特定的情况的实现，并不通用。一句话归纳原始的Specification Patern应用场合就是“拿出来后筛选”。

如果是这样的话，那规约模式是不是适合于仓储，适合于部分规则，而不适合于所有规则的实现？

我认为这是不对的，规格模式与契约模式(Design By Contact)是设计中两个非常通用的模式，在DDD中有以下用处：
1.验证：验证一个对象，看它是否满足某些业务要求，或者是否已经准备就绪，与状态有关。

2.筛选过滤：从一个集合中筛选出符合指定要求的对象。

3.按需创建：创建一个对象时指定该对象必须满足某种要求。

规格模式是针对领域模型的，不是仓储的。