什么时候不应该使用规则引擎？
我有一个相当不错的使用规则引擎的好处列表，以及使用它们的一些原因，我需要的是你不应该使用规则引擎
到目前为止，我所得到的最好的是：
规则引擎并不是真正意图处理工作stream或stream程执行，也不是旨在执行规则的工作stream引擎或stream程pipe理工具。
还有什么其他的原因，你不应该使用它们？
当我看到人们使用非常大的规则集（例如，在单个规则集中的数千个规则的顺序）时，我非常紧张。 当规则引擎是一个坐在企业中心的单身人士时，经常会发生这种情况，希望保持规则DRY可以让许多需要它们的应用程序访问它们。 我会藐视任何人告诉我，一个有很多规则的Rete规则引擎是很好理解的。 我不知道有任何工具可以检查以确保冲突不存在。
我认为分区规则的设置让它们变小是一个更好的select。 方面可以是在许多对象之间共享通用规则集的一种方式。
我更喜欢更简单，更多的数据驱动方法。
我将举两个例子，从使用规则引擎是一个坏主意的个人经验，也许这将有助于：
- 在过去的项目中，我注意到规则文件（使用Drools的项目）包含了大量的Java代码，包括循环，函数等。它们本质上是伪装成规则文件的java文件。 当我问build筑师他的devise理由时，我被告知“规则从来不打算由商业用户维护”。
教训 ：出于某种原因，他们被称为“业务规则”，当您无法devise一个可被业务用户轻松维护/理解的系统时，不要使用规则。
- 另一个案例; 该项目使用规则，因为需求定义不明确/常常改变。 开发团队的解决scheme是广泛使用规则来避免频繁的代码部署。
课程 ：在初始版本更改期间，需求往往会发生很大变化，不保证使用规则。 当您的业务经常更改（而不是要求）时使用规则。 例如： – 随着税收法律的变化，您的税收将每年发生变化，规则的使用是一个很好的主意。 随着用户发现新的需求，Web应用的1.0版本将会经常变化，但是随着时间的推移将稳定下来。 不要将规则用作代码部署的替代方法。
我是商业规则引擎的忠实粉丝，因为它可以帮助你使程序员的生活更轻松。 我在处理数据仓库项目时遇到的第一个经历就是find包含复杂CASE结构的存储过程，这些结构遍布整个页面。 debugging是一场噩梦，因为很难理解在这样长的CASE结构中应用的逻辑，并且确定代码的第1页的规则与第5页的规则之间是否有重叠。总的来说，我们有代码中embedded了300多个这样的规则。
当我们收到新的发展要求时，对于涉及3000多条规则的“会计目的地”（Accounting Destination），我知道有些事情需要改变。 那时候我一直在做一个原型，后来成为现在是自定义业务规则引擎的父级，能够处理所有的SQL标准操作符。 最初，我们一直使用Excel作为创作工具，之后，我们创build了一个ASP.net应用程序，它将允许业务用户定义他们自己的业务规则，而不需要编写代码。 现在系统工作正常，只有很less的错误，并且包含超过7000个计算这个记帐目的地的规则。 我认为这种情况不可能通过硬编码来实现。 用户非常高兴，他们可以定义自己的规则，而没有IT成为他们的瓶颈。
尽pipe如此，这种方法仍然有限制：
- 你需要有能力的商业用户对公司业务有一个很好的理解。
- search整个系统（在我们的例子中是数据仓库）的工作量很大，以便确定所有硬编码的条件，这些条件是有意义的，可以转换成由业务规则引擎处理的规则。 我们还必须谨慎对待这些最初的模板，以供商业用户充分理解。
- 您需要有一个用于规则创作的应用程序，其中实现了检测重叠业务规则的algorithm。 否则，最后你会得到一个大混乱，没有人了解他们得到的结果。 当您在像自定义业务规则引擎这样的通用组件中出现错误时，debugging和涉及大量testing非常困难，以确保以前工作的内容现在也能正常工作。
关于这个主题的更多细节可以在我写的文章中find： http : //dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
总体而言，使用业务规则引擎的最大优势在于，它允许用户收回对业务规则定义和创作的控制，而无需在每次需要修改某些内容时都去IT部门。 这也减less了IT开发团队的工作量，现在可以集中精力build设更多附加值的东西。
干杯，
尼古拉·
我注意到的那个“双刃剑”是：
把这个逻辑放在非技术人员手中
我看到这个工作很棒，当你在非技术方面有一两个多学科的天才时，我也看到缺乏技术导致膨胀，更多的错误，一般4倍的开发/维护成本。
因此，您需要认真考虑您的用户群。
我以为Alex Papadimoulis的文章很有见地： http : //thedailywtf.com/articles/soft_coding.aspx
这不是全面的，但他有一些好点。
关于何时不使用规则引擎…（以及何时使用）的伟大文章….
http://www.jessrules.com/guidelines.shtml
另一个select是，如果你有一个线性的规则只适用于一次，以获得一个结果是创build一个groovy接口，并让开发人员编写和部署这些新的规则。 优点是它速度很快，因为通常你会通过hibernate会话或jdbc会话以及任何参数，所以你可以有效地访问所有的应用程序数据。 有一个事实清单，可以有很多循环/匹配，真的可以减慢系统…..这是避免规则引擎，并能够dynamic部署的另一种方法（是的，我们的常规规则部署在数据库和我们没有recursion….它要么符合规则，要么没有）。 这只是另一个select…..哦，还有一个好处是没有学习传入开发人员的规则语法。 他们不得不学习一些常规，但这是非常接近的Java，所以学习曲线好多了。
这真的取决于你的上下文。 规则引擎有它们自己的位置，如果您对某个项目有规则，那么您可能需要dynamic部署规则引擎，而不需要规则引擎。
基本上不要使用规则引擎，如果你有一个简单的规则集，而且可以有一个常规的接口，就像dynamic部署一样，join你的团队的新开发人员可以比Drools语言更快地学习它（但是这是我的观点）
根据我的经验，当以下情况属实时，规则引擎工作得最好：
- 为您的问题域定义明确的学说
- 高质量（最好是自动化的）数据有助于驱动大部分input
- 访问主题专家
- 有创build专家系统经验的软件开发人员
如果缺less这四个特性中的任何一个，你仍然可能会发现一个规则引擎为你工作，但是每当我尝试了一个规则引擎，即使有一个失踪，我也遇到了麻烦。
这当然是一个好的开始。 规则引擎的另一件事是有些东西是很好理解的，确定的，直接的。 工资预扣是（或用来）是这样的。 您可以将其表示为规则引擎可以解决的规则，但是您可以将相同的规则表示为相当简单的值表。
所以，当你expression一个长期的过程时，工作stream引擎是很好的。 规则引擎可以做类似的事情，但是你必须做很多额外的复杂性。
当你有复杂的知识库并需要search时，规则引擎是很好的。 规则引擎可以解决复杂的问题，并且可以快速适应不断变化的情况，但是在基础实施上会带来很多复杂性。
许多决策algorithm都足够简单，可以expression为一个简单的表驱动程序，而没有真正的规则引擎所暗含的复杂性。
我强烈推荐像Drools这样的业务规则引擎作为开源或商业规则引擎（例如LiveRules）。
- 当你有很多本质上是波动的业务策略时，很难保持这部分核心技术代码。
- 规则引擎为框架提供了极大的灵活性，易于更改和部署。
- 规则引擎不是随处可用，而是在有许多策略定期不可避免地发生变化时需要使用。
我不太了解以下几点：
a）商业人士需要很好地了解业务，或者;
b）对商界人士的不同意见不需要知道规则。
对于我来说，作为一个刚刚触及BRE的人，BRE的好处就是让系统适应业务变化，因此它着重于适应变化。
如果在时间x设置的规则不同于在时间y设置的规则，这是否重要，因为：
a）商业人士不了解生意，或;
b）商界人士不懂规矩？
我前段时间在博客上写了一些内容。
你可以在这里查看 – > http://www.codetoglory.com/?p=21
当你有像保险，交易和外汇交易领域一样不断变化的dynamic规则时，你应该真的使用它。
希望我的博客文章能给你一些好的概述。
