可插拔业务规则的设计

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.按需创建:创建一个对象时指定该对象必须满足某种要求。

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