简单是王道《六、剖析一个工具样本》

上篇文章中提到一些不合理的工具，如业务规则管理系统（Business Rule Management System, BRMS)，因为它的畸形发展，而且嵌入应用系统的内部，给系统带来了不必要的复杂性。今天再围绕这个问题，深入地探讨一下。我会从下面四个方面来展开。

什么是BRMS？BRMS如何工作？问题在哪里？更好的方案。

什么是BRMS？首先声明一点，在应用系统中，业务规则是大量存在的，例如，银行的贷款业务，当自动化审核贷款申请的时候，牵涉到大量的规则：贷款人的年龄，收入，以往的信用记录，甚至贷款人所在的地区，种种因素决定了贷款的额度。业务规则管理系统的目标之一是把这些规则从应用系统的其他逻辑中剥离，并加以统一的管理（规则库，历史版本，安全控制等等）。我很赞赏这个想法。可是问题在于这仅仅是目标之一，随着业务规则管理系统的发展，这个工具被赋予了越来越多的使命，甚至为了市场而畸形化发展了。

一个最离谱的目标是把业务规则管理系统打造成业务人员的工具。让业务人员直接参与应用系统的实现。听上去是个不错的市场噱头，后面我会解释为什么这个目标存在问题。

BRMS如何工作？先让我们来看看这个BRMS系统到底有些什么内容。整个BRMS系统围绕BOM（Business Object Model）构建。BOM提供了一组抽象对象（底层可以是多种实现，java，Schema等等），规则就是对这些对象的操作（即获取和更新这些对象携带的数据）。为了使这些规则更具有自然语言的特征，这些对象上的操作首先被赋予一些有业务含义的词汇，然后定义了一些语句，组织这些操作形成一条规则。例如：

如果 贷款人的信用记录是 良好
那么 贷款额度 增加 百分之五十

为了使规则应用到系统的技术环境中，需要一个规则引擎来解释这些具有脚本特征的规则，运行期还需要把这些脚本和底层的实现关联起来，如java或xml，这里就牵涉到各种算法。因为底层实现如java对象，被载入到工作内存中供规则引擎使用时，通过一定的算法被快速定位和使用，从而实现在脚本规则中我们期望的结果。除此之外，规则通常并不是独立存在的，总是有一系列的规则以规则流的方式组合起来成为一个规则集。规则引擎同样需要处理这部分的工作。

好了，到此为止，我们需要一个开发环境，来编写具有业务含义的规则，来结构化这些规则，来画规则流程图，来调试规则，来进行规则的版本管理，来定义业务词汇，来发布规则，等等等等。我们需要一个web console，来团队化开发规则，来定义规则的访问权限，来发布规则，等等等等。我们需要一个运行规则的服务器，来集成到各种不同的环境（jee server, non jee server）。我们需要划分不同的角色，来担当规则开发过程中的各种工作。值得注意的是，在发布规则前，总是需要技术人员来校验，并完成最终的发布。这是为了保证规则不会遭到破坏。

问题在哪里？首先一个小的问题是，在规则发布的最后阶段，技术人员仍然要充当规则检验的角色。这使业务人员直接参与系统实现的期望大打折扣。业务需求直接以业务规则呈现？如果有规范的业务需求，为什么需要业务人员多此一举在规则开发环境中编写规则？这样的疑问可能大家暂时看不出有太大的问题，不过接下来将看到更大的问题。

接下来的问题是业务规则管理系统本身的发展，导致规则的迁移变得困难。规则语言发生变化，导致成千上万的规则变得面目全非。这是个现实的问题。

最关键的问题在于BOM。所有的规则基于BOM，当规则库发展到数以万计的规模，BOM的变化会导致不可收拾的局面。可以想象吗？那些业务词汇与底层实现脱节了，规则的价值就像股市的泡沫，顷刻间灰飞烟灭。没人敢保证BOM在应用系统的开发过程中不会发生变化。通常是经常发生变化，对吗？业界有种说法，应该采用自上而下的模式，即先有独立的业务词汇，然后才考虑各种实现。我期待这种方案，但我更期待它独立到与应用系统关系达到最大程度的松散性。

更好的方案。我们不妨回头看看规则的简单本质。一组对象和基于对象的操作，并且这些具有规则特征的对象和对象操作被独立于其他的逻辑。一个编程模型完全可以解决这个问题。好处是，编程模型不需要成本，编程模型被技术人员使用。技术人员需要和业务人员沟通，并期望业务人员整理出清晰的规则描述。让业务人员直接参与系统的实现，最终又需要技术人员来校验和发布，除了市场噱头，看不出有何意义？

前面的文章中也提过，我不反对使用工具。我赞成那种用完即可弃的工具。象业务规则管理系统这种工具，一旦在应用系统中使用，将无法摆脱，并导致各种问题。这才是我反对的。

在应用系统的开发过程中，有些问题总是被忽视。特别是各个角色和阶段的产物总是被零零碎碎地生产。这是非常不对的。在以后的文章中我会提一提开发模型。