【问题标题】:Separating Business Rules from Business Processes将业务规则与业务流程分开
【发布时间】:2010-11-21 20:59:22
【问题描述】:

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

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

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

感谢和问候,
阿杰

【问题讨论】:

  • 规则引擎有什么问题?
  • 这个问题是有效的,但是那个放-1的人,你能不能露面并评论一下这个问题有什么问题?我给有效问题 +1。
  • 我的应用程序域不需要非常复杂的规则,其中包含多个取决于上下文等的参数,所以我觉得规则引擎将成为架构上的臃肿。
  • 您使用哪种语言?例如,AspectJ 提供了强大的功能,而 .NET AOP 解决方案似乎没有那么大的功能。
  • 詹姆斯感谢您的评论。我正在使用 .Net (C#)。

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


【解决方案1】:

您可以使用多种技术将规则与流程分开。在某种程度上,您正在从业务流程的各个点调用“方法”。那么问题就变成了一种机制,通过这种机制可以在不改变业务流程本身的情况下修改该方法。

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

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

如果复杂度足够高,您会发现您已经实现了自己的规则引擎。

在某些时候,使用现有规则引擎比重新发明这个轮子更有效。

如需更详细的建议,您需要告诉我们更多有关您在做什么的信息。

【讨论】:

    【解决方案2】:

    问题范围很广,所以我将按照一般模式回答。

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

    实际规则本身保存在工作流之外,可以独立于它进行修改。诀窍是限制规则评估的“过程结果”,以便可以继续拥有可预测(和可测试)的过程。

    【讨论】:

      【解决方案3】:

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

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-04-03
        • 1970-01-01
        • 2011-03-15
        • 1970-01-01
        • 2011-07-05
        • 1970-01-01
        • 2012-01-26
        • 2019-08-07
        相关资源
        最近更新 更多