当我们使用了BRMS，技术人员被要求验证业务规则的正确性。他还需要了解业务逻辑吗？如果不需要了解，如何进行验证呢？按照BRMS的说法，业务需求将直接以业务规则的方式呈现。如果客户能够清晰地整理规范的业务规则，写在规则编辑器中和写在需求文档中有什么本质的区别呢？无论写在哪里，都离不开技术人员的参与。那么，提供一个规则编辑器，大连外贸客户管理软件除了满足客户参与系统实现的愿望，还有什么其他的意义呢？从这个角度来看，BRMS的意义只是提供了一个整理业务规则的方法而已，并没有什么特殊的价值。当然，这是个画蛇添足的问题，但并不致命。接下来，我们来看一些真正严重的问题。如果定义业务词汇和组织业务语句可以为我们带来革命性的变化（例如，BPM），我们也许会尝试克服革命带来的一些副作用，但是BRMS的确毫无是处。

 BRMS带来的一个严重问题，就是由于它自身的发展，导致了规则迁移变得困难。比方说，当规则语言发生变化时，就会导致成千上万的规则面目全非。这是个非常现实的问题。在开发大连外贸客户管理软件中我曾多次降低人工成本，那么软件定制价格由什么决定呢?简直痛不欲生。BRMS带来的另一个严重问题，来自BOM。我们曾经在前面谈到，所有的业务规则都是基于BOM的。当规则库中的业务规则发展到数以万计的规模时，BOM的变化将会导致不可收拾的局面。想象一下，我们定义的业务词汇与底层实现脱节了，太可怕了，规则的价值就像股市的泡沫，顷刻间灰飞烟灭。BOM的变化不是一个小概率事件，有谁敢保证BOM在企业应用系统的演变过程中不会发生变化呢？它会经常发生变化。
     业界有种说法，BRMS在用于业务规则生产时，应该采用自上而下的模式，即先有独立的业务词汇，然后才考虑各种实现（更加自动化）。我愿意看一看这种方案的效果，但我更期待BRMS能够独立到与应用系统的关系达到最大程度的松散性。什么是更好的方案？在大连外贸客户管理软件开发中，我们不妨回头看看业务规则的本质。所谓业务规则，就是一组对象和基于对象的操作，这些具有规则特征的对象和对象操作被抽取出来，独立于系统中其他的逻辑。业务规则的本质看上去非常简单。实际上，建立一个编程模型，就完全可以解决这个问题。使用编程模型的好处是，它不需要购买BRMS，它更容易调试，而且拥有更好的性能。