可插拔业务规则的设计

13-06-25 Pescod
因为业务需求迅速变化着，规则也每天都在变化。如何处理这些变化，从而使我们的系统更加有效的可维护、可重用和可扩展？

1.规约（Specification）模式

2.规则对象

3.规则引擎

4.规则也是业务的一部分，需要使用领域驱动设计根据具体情况来具体对待

由于没有具体实践过，不知道该怎么选。不知道大家有什么意见或其他的方法？

[该贴被Pescod于2013-06-25 05:59修改过]

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

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

Pescod
2013-06-27 04:05
规约（Specification）模式

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

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

banq
2013-06-27 08:52
2013-06-27 04:05 "@Pescod
"的内容
而且是面向特定的情况的实现，并不通用 ...


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

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

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

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