将业务规则与业务流程分离

时间:2009-08-22 07:56:15

标签: design-patterns architecture aop business-logic-layer

如何从业务流程外部化业务规则,以便我可以在不触及业务流程逻辑的情况下添加规则?

例如,我有两个业务流程,比如“添加产品”和“更新产品”,这两个流程共享一些常用规则,规则可以在以后继续添加。我打算编写业务流程一次,执行特定流程的所有可用规则,如果没有抛出异常,继续成功完成业务流程。

我不打算使用规则引擎,因为我认为这对我的架构来说可能太重了。

谢谢和问候,
阿贾伊

3 个答案:

答案 0 :(得分:1)

这个问题的答案比我在这里写的要复杂得多。这涉及到您的业务/行业的数据关系,安全性,政策原则和行政约束的科学。

如果你的意思不如“商业规则”和“商业政策”那么模糊,我可能会误解你的问题。

答案 1 :(得分:1)

您可以使用许多技术将规则与流程分开。在某种程度的abstarction中,您从业务流程的各个角度调用“方法”。然后,问题成为可以在不改变业务流程本身的情况下修改该方法的机制之一。

可以将方法打包在自己的库(dll,jar或其他)中,并用新版本替换该jar。更改库,更改业务规则。

可以根据从数据库获得的可配置参数来表达方法中的逻辑。更改数据库,更改业务规则。

如果复杂性上升到足以发现您已经实施了自己的规则引擎。

在某些时候,使用现有的规则引擎变得更有效率,而不是重新发明这个轮子。

如需更详细的建议,您需要告诉我们您正在做的事情。

答案 2 :(得分:0)

问题非常广泛,所以我将回答一般模式。

在许多情况下,我所做的是定义流程,以便在流程的适当阶段插入一些“守门员”活动。这些守门人中的每一个都负责执行业务规则的特定子集。因此,例如,一个这样的活动可能会强制执行数据质量。另一个可能基于业务规则做出路由决策。另一种定价。等等。

实际规则本身保存在工作流程外部,可以独立修改。诀窍在于约束规则评估的“过程后果”,以便人们可以继续拥有可预测(且可测试)的过程。