规则引擎的使用如何影响应用程序的设计，实现和性能？

我对规则引擎的能力感兴趣：

• 启动并迭代业务驱动逻辑
• 让“业务用户”而不是开发人员执行这些规则的实际修改
• 大致理解业务规则

另外，使用规则引擎是否会影响应用程序的质量？

如果要部署到一台计算机的安装程序，架构与使用数千台计算机的多层基于云的分布式架构，规则引擎的使用是否会发生变化？会有什么不同？

是否为非技术人员公开接口以修改业务规则的决定很大程度上取决于几个因素，包括项目目标，项目成本，项目寿命以及项目中已知与未知的比率。项目。

例如，如果我认为没有人会使用规则接口，那么我可能会选择退出实现它。但是，如果我有理由相信更改会很频繁，并且不同的最终用户会期望采用不同的规则，那么我将考虑构建此类功能。

我选择在一个项目上执行此操作，并且花了好几年时间才广泛使用该功能。我怀疑最终会有最终用户想要自己定制事物的最终用户，因此我们分步实现了此功能。

它开始时只有某些人（例如开发人员或管理员）可以使用。界面笨拙，但是如果您知道自己在做什么，就可以使用。但是当产品即将完成时，规则引擎后端逻辑就派上用场了，我们的设计团队为它提供了一个漂亮的，面向客户的用户界面。

如果要做不同的事情，可能会因为学习难度很大而选择其他数据库体系结构。简而言之，尽早构建它会导致许多面向客户的功能，而后又不必为重新编写代码并将其重构以包含所有动态规则而烦恼。

如果要这样做，我将创建一种特定于域的语言来表达规则，并可能给biz类型一个UI，以便在需要时对其进行修改。然后使用一种功能语言（例如Haskell，Lisp或Erlang）来评估规则。

如果需要大规模并行处理，我会选择Erlang，它的并发性很好。使用Erlang可以很好地将节点从1个扩展到100个或更多。

如果您将规则视为将应用于数据集的代数，那么逻辑上确定代码中的需求并向自己（或您的经理）证明它是正确的变得容易得多。这是功能语言对您有利的地方之一。

我写了一个基于WF（Windows工作流基础）的应用程序。我的老板（DBA）深信WF可以执行多线程而无需计划并发。记忆被彻底地划分了，但是有太多的问题，我无法在短短的几段中解释它，并且它与您的问题只是有点关系...所以我继续。

迭代BL的能力：
WF做得很好。
允许非技术人员“构建应用程序”：
如果架构有效且非技术人员了解技术局限性，那么WF可以做到这一点……我们没有。
通常具有理解业务规则的能力：
有些加载项可以完成一些基本工作，就像Sharepoint可以自动化工作流一样。我没有进入这些项目。
软件发布的质量：
平庸。WF对于我们的目的而言表现不佳，但是系统设计不当，我的双手被束缚。
应用速度：
慢。对于开发人员和最终用户而言，学习曲线都非常陡峭。WF分离内存（我记得应用程序域）的方式使跨线程通信，互斥体和其他线程概念陷入混乱，甚至根本无法工作。

最终，我编写了一个原型来证明WF的实现方式失败。我用普通的多线程代替了它。性能和代码可读性提高了。带着一点盐，因为这是我的第一个专业WF应用程序。

非技术人员可以相信，不需要程序员就可以实现几乎所有可能，这对BL的整个“虚拟灭亡”都是不利的。与此相关的社会学问题扼杀了该项目。

如果我可以按照自己的方式做，请使用：使用传统的螺纹加工和通过Decorator Pattern实现的BL成型。 我写了使用这些技术的概念证明，并且效果很好。 与 B1映射应该被包裹在一个简单的用户界面。
更新
我发现在处理并发问题时写的一篇旧文章。该代码显示了在并行工作流中打印“ hello world”是如何在不了解幕后内容的情况下工作的（这违背了WF抽象的全部目的）。MSDN主持人解释了并行活动实际上是如何顺序的高级概述。他的结论基本上是“您需要阅读整个手册”才能做一些基本的事情。 http://social.msdn.microsoft.com/Forums/zh-CN/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

祝好运。

从Java代码连接到Oracle规则引擎的经验还不够完善。其中一些可能是由于规则作者的经验不足，但这就是我所面临的。

• 我们将规则引擎实现为无状态设备。调用者必须收集所有参数并将其传递给引擎进行评估。这意味着，如果规则需要另一个数据字段，则所有客户端都需要更新。这抵消了吹捧的优势，即能够独立于其使用者来更新规则。
• 该引擎发布了SOAP WSDL，但是它是从规则集自动生成的。规则的微小更改会破坏与消费者的合同。
• 引擎擅长评估规则，但很难告诉我们评估失败的原因。很难将信息错误消息反馈给用户。
• WSDL不适合一般消费。最简单的规则集有一个14页的WSDL，它公开了规则库的内部。我们必须在前面放置一个SOA转换层，以呈现一个业务友好的外观。因此，在循环中有两个额外的服务器，而不是调用100％可靠的本地库。这至少不会增加可靠性。再加上对规则签名的任何更改，都需要三个不同的团队来更新代码。不是我对敏捷的定义！
• 每当规则集需要添加时，就必须更新WSDL，这意味着客户不再了解它。这导致为v2，v3 ..添加新的SOAP端点，这具有需要更新防火墙规则的连锁效应。
• 规则以“结构化英语”表示，对于简单规则而言很容易理解，但对于复杂规则则几乎不透明。
• 我们永远找不到知道规则编写语言的承包商。
• 规则语言未实现数组，递归或面向对象。在一种情况下，实现规则的唯一方法是通过Excel电子表格的标注，其中在VB中实现了规则。何必？

我认为使用规则引擎（或不使用规则引擎）的选择并不明确。我建议您为要使用的任何引擎制作原型，然后做出明智的决定。他们当然不是灵丹妙药...