合并了规则引擎的系统曾经真正成功过吗？

Question

我们的系统(外来商品衍生品交易捕获和风险管理)很快就会重新开发。我听到的一个建议是，将合并一个规则引擎，以使最终用户(相当复杂的商品交易员)更容易对业务逻辑进行某些更改。

我对规则引擎有点怀疑。我内心的敏捷主义者想知道它们是否仅仅是一个过程问题的技术解决方案…即。我们的开发人员需要很长时间才能响应业务的变化需求。这个问题的解决方案应该是一种更具协作性的开发方法，更好的测试覆盖率，更灵活的实践。

听到规则引擎确实是一件好事的情况(特别是在交易环境中)肯定会有所帮助。

Answer 1

我已经看到两个应用程序使用了来自Fair Issac的Blaze Rete引擎。

一个应用程序将数千条规则塞进了一个知识库，有可怕的记忆问题，已经成为一个很少有人理解的黑匣子。我不会称之为成功，但它正在生产中运行。

另一个应用程序使用决策树来表示医疗表单上数百个问题的顺序，以处理客户。它做得如此优雅，以至于业务人员可以根据需要更新规则，而不必涉及开发人员。(不过，还是要由一个人来部署。)我认为这是一个巨大的成功。

因此，这取决于问题的聚焦程度，规则集的大小，开发人员的知识。我的偏见是，简单地让规则引擎出现单点故障并将规则倾倒其中可能不是一种好的方法。我会从数据驱动或表驱动的方法开始，然后不断发展，直到需要规则引擎。我还努力将规则引擎封装为对象行为的一部分。我会对用户隐藏规则引擎，并尝试将规则空间划分为域模型。

Answer 2

我不知道我是否会说它们是真正的恩惠，但我认为它们肯定是有价值的。我在保险行业的一个系统上工作了几年，其中使用了一个非常成功的规则引擎，允许业务用户创建规则来确定哪些策略是合法的，这取决于国家。

例如，如果你必须在某些州拥有共同保险，或者出于产品考虑，或者因为州法律规定这是非法的，某些免赔额和共同保险的组合是不允许的。

公司运营所在的州的数量，以及规则(季度)的不断变化，将使这成为一种令人眼花缭乱的编码实践。更重要的是，这不是程序员的专业技能。它增加了额外的无意义的通信，其中最终用户正在向不像他们一样是保险行业专家的程序员描述要实施的规则。

如果设计正确，规则引擎仍然可以启用允许良好测试的工作流系统。在本例中，规则存储在数据库中，并且有QA和PROD数据库。因此，BA可以在QA中测试他们的规则，然后将其提升为PROD。

就像任何事情一样，它通常是关于实现的，而不是实际的技术。

Answer 3

是的，微软在BizTalk中有一个业务规则引擎(BRE)，已经成功使用了多年。我听说他们的客户购买BizTalk (非常昂贵)仅仅是为了BRE。

根据我的经验，让业务用户更新规则的实用性微乎其微。通常需要一个技术人员来处理业务规则编辑器。