我正在审核一个使用所谓的规则引擎 http://en.wikipedia.org/wiki/Business_rules_engine。简而言之，这是一种从应用程序代码外部化业务逻辑的方法。
这个概念对我来说是全新的，我对此非常怀疑。听到人们谈论后贫血领域模型 http://www.martinfowler.com/bliki/AnemicDomainModel.html在过去的几年里，我一直在质疑规则引擎方法。对我来说，它们似乎是削弱领域模型的好方法。例如，假设我正在做一个与规则引擎交互的 java web 应用程序。然后我决定拥有一个基于同一域的 Android 应用程序。除非我希望 Android 应用程序也与规则引擎交互，否则我将不得不错过已经编写的任何业务逻辑。
由于我还没有任何使用它们的经验，只是好奇，我有兴趣了解使用规则引擎的优点和缺点？我能想到的唯一优点是，您不需要仅仅为了更改某些业务规则而重建整个应用程序（但实际上，有多少应用程序确实有那么多更改？）。但使用规则引擎来解决这个问题对我来说听起来有点像在猎枪伤口上贴创可贴。
更新 - 自从写这篇文章以来，上帝本人，马丁·福勒，已经关于使用规则引擎的博客 http://martinfowler.com/bliki/RulesEngine.html.
我见过的大多数规则引擎都被系统代码视为黑匣子。如果我要构建一个域模型，我可能希望某些业务规则是域模型固有的，例如业务规则告诉我对象何时具有无效值。这允许多个系统共享域模型，而无需重复业务逻辑。我可以让每个系统使用相同的规则服务来验证我的域模型，但这似乎削弱了我的域模型（正如问题中指出的那样）。为什么？因为我不是始终在所有系统上一致地执行业务规则，而是依靠系统程序员来确定何时应执行业务规则（通过调用规则服务）。如果域模型完全填充，这可能不是问题，但如果您处理的用户界面或系统在其生命周期内更改域模型中的值，则可能会出现问题。
还有另一类业务规则：决策。例如，保险公司可能需要对承保申请人的风险进行分类并得出保费。您可以将这些类型的业务规则放置在域模型中，但是对于此类场景的集中决策通常是可取的，并且实际上非常适合面向服务的体系结构。这确实引出了一个问题：为什么是规则引擎而不是系统代码。规则引擎可能是更好的选择的地方是负责决策的业务规则随着时间的推移而变化（正如其他一些答案所指出的那样）。
规则引擎通常允许您更改规则，而无需重新启动系统或部署新的可执行代码（无论您从供应商那里收到什么承诺，请确保在非生产环境中测试您的更改，因为即使规则引擎是完美的，人类仍在改变规则）。如果您在想，“我可以通过使用数据库来存储更改的值来做到这一点”，那么您是对的。规则引擎并不是一个可以做新事情的神奇盒子。它旨在成为一个提供更高级别抽象的工具，以便您可以减少重新发明轮子的精力。许多供应商更进一步，让您创建模板，以便业务用户可以填补空白，而不用学习规则语言。
关于模板的最后一个警告：模板永远不会比编写没有模板的规则花费更少的时间，因为模板至少必须描述规则。规划更高的初始成本（就像您要构建一个使用数据库存储更改值的系统，而不是直接在系统代码中写入规则一样） - 投资回报率是因为您节省了系统代码的未来维护费用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
