我正在做类似于您想做的事情。
由于这些业务规则通常由企业执行，因此我希望企业通过GUI对规则进行必要的更改。
警告警告警告！！！
一个普遍的误解是，只要有GUI，非程序员都可以使用它。那不是我得出的结论。它有帮助，但是编程的难点不是写代码，而是针对正确的问题提出了很好的解决方案。我敢肯定，一些更聪明，技术上更偏向商务的人可以用Guvnor做事，但是不要指望这是通向“极乐世界”的黄砖路。您仍然必须为业务人员提供一个理智的数据模型和API，使他们可以执行所需的工作，但可以防止他们偶然地执行不需要的操作。
1. Drools是否支持轻量级GUI来编辑规则？
2. Drools Guvnor是轻量级的GUI，还是有降低它的方法？
好吧，“轻量级”是个讨论的话题，但是Guvnor的表现相当不错，不需要浏览器，因此我认为还可以。
3.将应用程序集成到Guvnor以阅读规则有多容易？
好了，一旦您启动并运行了Guvnor，连接您的应用程序以使用a
KnowledgeAgent连接到Guvnor并监听新的规则更新就不是特别困难。
不幸的是，一般来说Drools尤其是Guvnor都有很多怪癖，您可能需要解决（例如，您必须分解Guvnor WAR文件并在WEB-INF /
beans.xml中编辑文件才能设置非默认配置…）。但是，一旦您弄清楚了，我认为它会很好地工作。
至于文档，Javadocs有时可能会比较稀疏，但是该网站上有很多不错的东西，包括几本书。
总而言之，Drools和Guvnor是功能强大的工具，但让它们正常工作并非易事。如果您确实 需要
他们所提供的功能，那么他们是值得的，但是也可能值得考虑是否需要一个更简单的脚本解决方案。
现在，如果您发现自己确实需要Drools，这是我的首要建议- 为数据库和规则保留单独的数据模型 。这确实意味着有很多无聊的转换代码要编写，但这是值得的。
我正在使用的应用程序将JPA用于数据库事务，并且在我们的规则中使用该数据模型并不是很令人愉快。几个原因：
适合您的数据层并不一定适合Drools，反之亦然。
我们有一个树状结构，在JPA中自然是
@OneToMany与父节点列表中的子级有关系。在Drools中使用列表非常麻烦，因此我们将其展平为一个结构，在该结构中插入一个
ParentNode对象和一堆
ChildNode对象，使用起来要容易得多。
敢于重构。
规则的数据模型也需要存在于Guvnor中-这意味着如果重命名实体类或类似的东西，则可能会破坏所有规则。规则的单独数据模型意味着您可以无忧地重构数据库内容。
向他们展示他们需要看的东西。
数据库可以变得相当复杂，但是规则通常不需要关心其中的许多复杂性。将这些复杂性暴露给人们编辑规则可能会导致很多不必要的混乱。例如，我们发现对于我们的场景，绝对不需要使规则编写者暴露于多对多关系（事实证明，在Drools中处理起来非常复杂）-因此，我们使它们看起来像一对多，一切都会变得更加自然。
保护。
我们已经将大多数规则设计为像以下伪代码一样工作：
rule "Say hello to user"when user : Userthen insert(new ShowMessageCommand("Hello " + user.getName() + "!"))end…因此，对于每个规则包，都明确定义了您可以插入哪些响应命令以及它们的作用。在我们的应用程序中运行了规则之后，我们选择由规则插入到会话中的对象并对其进行操作（事实证明，访问者模式对于避免长的
ifinstanceof/
else if instanceof/
else连锁非常有用）。
我是不是让规则作家很高兴我们这样做了，做任何他们 认为 他们想与我们的JPA对象做。
无论如何，希望这会有所帮助。
