规则 vs. 过程性代码

在基于 BPM 的解决方案中，怎样确定何时适合使用规则，何时适合使用过程性代码呢？最近， haley.com 的创始人兼主席 Paul Haley 被请求帮助解决这个问题：

最近，一个企业架构群里的一些战略决策者们请求协助，以制定与他们企业更加相关的规则。他们既关注何时将规则嵌入中间层、何时将它们封装到服务中，也关注典型用例和参考实现。他们对规则怎样与 BPM 和 BI 结合特别感兴趣。

Paul 宣称传统 IT 思想偏向于编写过程性代码，这导致了对 BPM 的滥用。为了提供一个更为均衡的观点，他确定了两个需要理解的基本项：

1. 规则技术适合的抽象活动
2. 何时以及为何，规则技术比常见的选择更好

现今的 BPM 产品都包含一些结合规则的机制，但是 Paul 认为，目前的实现正在阻碍这种技术发挥其真正的能力：

时常，用户不知不觉就牺牲了市场时机，以及将逻辑从流程中分离所带来的灵活性、敏捷性和可访问性的优点。 其关键之处就是 BPM 不会推动更广泛地运用业务规则。更确切的说，BPM 供应商只是应付那些知道在他们的流程中需要决策、并且规则比代码或流程图更适合管理他们决策的人。

那么，你该如何开始在普通的、BPM 规定的用例之外利用规则技术呢？Paul 提供了一些“规则的蓝图”：

在规则可能有效时会有明显的启发式逻辑（heuristics）。一些启发式逻辑以任务为中心，比如在决策制定或服从上。例如： - 是否有许多合格（或不合格）的标准（或原因）

• 是否有许多标示问题的异常（像突发的或者不符合规定）

在第一种情况下，决策是两个互相排斥的选择之一。对业务规则来说，这是最简单的情况。这种情况进一步被改进为：

• 当标准数量增加
• 当标准的集合变得更为动态
• 当标准变得更加复杂

规则技术典型适用的一个领域就是确定异常并强制服从，Paul 写到：

在监察应用（compliance applications）中异常是很普遍的。大多数规章都被表示为需求。换句话说，它们更趋向于说必须是什么，而不是该去做什么。任何这样的需求都必须被转换为推演规则或者执行动作的操作。典型来说，这样的转换包含替换“必须”、“可能”、“将要”，并引入“如果”或“如果不”。 很不幸，一条需求往往被转换为多于一条的规则。

从需求到业务规则的分析转换，如果对应关系大于一对一或者影响多个类、任务或者流程，那这就是使用规则技术的清晰的信号。

注意，策略也可能常常被表示为需求，但是它们也是经常被表示为规则。所以除了业务需求和规章外，策略也可能被强制使用异常，或者要求转换。

将异常逻辑作为规则进行维护，无需说明需求、规章、策略怎样（或就是）被（重复地或明显地）检查到，就可以识别异常、并在整个业务流程中强制服从规则。也就是说，从一个流程图中分离出需求（包括多数规章和一些策略）会显著增加生产率和敏捷性。

同样，规则可以用于评分算法中：

……由于主题专家认识到启发式逻辑，或者随着风险、盈利能力或其它关键业绩指标之间的相关性被发现，规则的使用会使搭建一个可伸缩的评分架构更容易。

然后 Paul 论述了一些规则技术何时不合适的指标，包括“如果流程简单就不要考虑规则”：

如果下面两条都符合，就不要使用规则： - 流程图只有少数分支节点

• 逻辑已经被完全理解并不会再改变

在将规则封装成服务方面，Paul 提出了下面的建议：

一般的讨论关心的是在对象还是在服务中封装业务逻辑（即规则）。服务对业务流程编制决策和监察是有意义的。

并且继续指出：

如果需求、规章、策略或规则覆盖模型中的很多类、流程中的很多任务，分离出来的规则就要被明确地表示出来。

总结文章时，Paul 对当前缺少 BPM 和 BRM 产品之间的整合持批评意见：

当今市场的现实是，BPM 供应商提供的业务规则能力并不具备早期提到的规则供应商具备的那些易访问性、可管理性、功能性和性能。并且顶级 BPM 供应商和规则供应商之间的合作还不够深入。 集成能力的局限性势必会影响在有一个 BPM 平台时使用规则。即使一些供应商的能力相对于专业的规则供应商来说较薄弱，这些供应商提供内置的能力也可能是最可行的选择。但是，这样做却使供应商更加禁锢在自己关注的问题中。

Paul 提到了 JBoss Drools （ InfoQ 曾对其进行过报导），因为它可能具有目前在 BPM 解决方案中推行规则技术最好的整合。

查看英文原文： Rules versus Procedural Code - - - - - -

译者简介： 王丽娟（Ivy Wang），一个快乐的程序员，持续从事 Java EE 中间件和 Java EE 企业应用的开发，关注软件架构技术。职业目标是成长为一名优秀的架构师。