我们已经很清楚了，业务人员（客户）并不能独立完成业务规则的开发，在这种情况下，在大连业务人员管理软件开发的成本主要是由程序员的时间所决定，不如更踏实地帮助客户完成业务规则（需求）的整理和优化。在我设想的编程模型中，业务规则将成为系统中一个独立的组成部分。它可以和BRMS能够做到的一样清晰，除了不能制造客户直接参与系统实现的“伪兴奋点”之外。 前面已经说过，我不反对使用工具。相反，我非常想知道大连业务人员管理软件开发使用哪些软件开发工具。可是，像BRMS这种工具，一旦在系统中使用，将长期无法摆脱，而且必须承受它带来的各种问题。这种工具才是我真正反对的。 

最后，我想引用Martin Fowler的一篇博客。在这篇文章中，提到了规则引擎，其中的某些想法和我的想法比较接近（Martin没有提到的一点是，当你使用了某些工具，也许在很长的一段时间内将无法摆脱噩梦）。我们真的要谨慎使用工具。 规则引擎提供了一种新的计算模型。和一般的命令模型（带有条件和循环的顺序执行指令）不同，它提供了一组产生式规则。每个规则有一个条件和一个操作，简单地说，你可以认为是一堆的if-then语句。 微妙之处在于，那些规则的编写顺序是任意的，系统执行它们的顺序也是任意。可以这样来想，系统处理所有的规则，选择那些条件为真的，然后做相应的操作。这样做好的地方是，很多问题都很自然地满足这种模型： if car.owner.hasCellPhone then premium+=100 if car.model.theftRating＞4 then

premium+=200；if car.owner.livesInDodgyArea then premium+=300； 规则引擎是工具，它让使用这种计算模型的程序变得更简单了。它也可能是个完整的开发环境，或者是可以和传统的平台一起工作的框架。我这些年看到的大多数都是那种运用在现有平台上的工具。

             同时，也有用这样的工具来构建整个系统的思想。不过现在聪明的人士倾向于把规则引擎仅仅作为系统的部分地方。产生式规则计算模型最适用的还是计算问题的一个子集，所以规划好大连业务人员管理软件开发成本是提高企业利润的重要举措。 你自己也可以构建简单的规则引擎。要做的是创建一堆带有条件和操作的对象，把它们存在一个集合中，然后运行它们，评估条件执行操作。通用的规则引擎提供了方法来描述规则，执行得更加有效。指定规则的技巧可以使我们不用考虑API，而是这样来描述规则、JAVA对象、表达规则的DSL或者录入规则的GUI。更有效率的执行引擎使用指定的算法（如RETE算法）来快速评估数以百计的规则上的条件。