我正在做一些类似于你想做的事情。
由于这些业务规则通常由企业制定，因此我希望企业通过 GUI 对规则进行必要的更改。
警告警告警告！！！这是一个常见的误解，认为只要有 GUI，非程序员就可以使用它。这……不是我得出的结论。它很有帮助，但编程的困难部分不是编写代码，而是针对正确的问题提出良好的解决方案。我确信一些更聪明、更倾向于技术的商业人士可以使用 Guvnor 做一些事情，但不要指望它会成为通往神奇极乐之地的某种黄砖路。您仍然必须为业务人员提供健全的数据模型和 API，让他们可以做他们需要做的事情，但又可以防止他们意外地做他们不想做的事情。
1. Drools是否支持轻量级GUI来编辑规则？
2. Drools Guvnor 是一个轻量级 GUI，还是有办法降低它的性能？
好吧，“轻量级”是讨论的主题，但 Guvnor 工作得相当好，并且只需要浏览器，所以我认为还可以。
3. 将应用程序集成到Guvnor以阅读规则有多容易？
好吧，一旦你启动并运行了 Guvnor，就可以连接你的应用程序以使用KnowledgeAgent连接到 Guvnor 并监听新规则更新并不是特别困难。
不幸的是，Drools 一般来说，特别是 Guvnor 有很多怪癖，您可能必须解决这些怪癖（例如，您必须分解 Guvnor WAR 文件并编辑 WEB-INF/beans.xml 中的文件以设置非默认配置...）。但一旦你弄清楚了这一点，我认为它的效果就很好。
至于文档，Javadocs 有时可能有点稀疏，但是web site http://www.jboss.org/drools/documentation有一些非常好的东西，包括几本书。
总而言之，Drools 和 Guvnor 都是强大的工具，但让它们发挥作用并非易事。如果你真的need他们所提供的东西是值得的，但如果更简单的脚本解决方案就足够了，也可能值得考虑。
现在，如果您发现自己确实需要 Drools，这是我的首要建议 -为您的数据库和规则保留单独的数据模型。这确实意味着需要编写很多无聊的转换代码，但这是非常值得的。
我正在开发的应用程序使用 JPA 来处理数据库事务，并且在我们的规则中使用该数据模型并不是很令人愉快。几个原因：
适合您的数据层的不一定适合 Drools，反之亦然。
我们有一个树结构，在 JPA 中自然是一个@OneToMany与父节点列表中的子节点的关系。在 Drools 中使用列表是相当痛苦的，因此我们将其扁平化为插入一个列表的结构ParentNode对象，以及一堆ChildNode对象，这更容易使用。
敢于重构。
规则的数据模型也需要存在于 Guvnor 内部 - 这意味着如果您重命名实体类或类似的东西，您可能会破坏所有规则。规则的单独数据模型意味着您可以毫无顾虑地重构数据库内容。
向他们展示他们需要看到的内容。
数据库可能变得相当复杂，但规则通常不需要关心其中的许多复杂性。将这些复杂性暴露给编辑规则的人可能会导致很多不必要的混乱。例如，我们发现对于我们的场景，绝对没有必要将规则编写者暴露给多对多关系（事实证明这在 Drools 中处理起来非常复杂） - 因此我们让它们看起来像一对多，一切都变得更加自然。
保护。
我们设计的大多数规则都像下面的伪代码一样工作：
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
...因此，对于每个规则包，都明确定义了您可以插入哪些响应命令以及它们的作用。在我们的应用程序中运行规则后，我们挑选出规则插入到会话中的对象并对它们进行操作（访客模式 https://secure.wikimedia.org/wikipedia/en/wiki/Visitor_pattern#Java_example事实证明对于避免长时间的使用非常有用if instanceof/else if instanceof/else链）。
我很高兴我们这样做了，而不是让规则编写者为所欲为think他们想要处理我们的 JPA 对象。
无论如何，希望这会有所帮助。
