规则引擎 Drools 使用解析

看了之后还是不明白了。呵呵，

我对规则引擎的理念也很感兴趣，但是联想到实际的工作场景，我发现Drools并没有想象中的完美，以下疑问请教众位大侠：

1.规则里面很多的判据不是直接就具备的，需要一些整理过程，那么这些整理过程到底是在Java类里面做还是在Drools规则里面做？举例子说：
规则如下：
如果用户购买的商品中有两个以上的A产品和一个B产品就打85折。
如果用户购买的商品中有两个以上的B产品，就打8折。

在实际开发中，我们会把用户准备购买的产品都放在一个列表中。
如果要应用规则引擎，直接以产品列表为“事实”是最理想的，但是以直接以产品列表为“事实”就需要在规则中插入Java代码，用来整理出产品A和产品B的数量。这样一来，整理产品列表的Java代码就脱离了Java的运行环境，调试起来比较困难。至于更复杂的一些业务规则，用Rule去实现岂不是很难阅读和理解？

如果我们不直接以产品列表为"事实"，而已采购的产品A和B的数量为事实，那么在调用规则之前，就要在Java中整理产品列表，求出产品A和B的数量，然后将其作为“事实”调用规则。此种方案的缺点就是不够灵活。一旦规则变化了，需要纳入产品C的数量来作为打折的依据，那么既要修改Java中整理产品列表的代码，又要修改规则文件。这也是我们不愿意看到的场面！


2.所谓的“业务规则”和“业务逻辑”区别到底在哪？是不是所有业务逻辑都可以看做是“业务规则”？如果是这样，那么复杂的业务逻辑或者说复杂的业务规则用规则文件去编写是否合适？如何把握将哪些业务规则用规则引擎去实现的度？

3. 如果要推入工作内存的事实量较大，或者需要用到的规则量较大，规则引擎的性能可否满足要求呢？

4. “部门经理（角色）能够批准2天以内的请假，总经理（角色）可以批准2天以上的请假”，这样的规则算不算业务规则？这样的规则中，什么是事实，什么是结论？在工作流的场景下，我期望的是给出申请的请假天数，然后根据业务规则找出可以批准的角色，然后将工作任务发给该角色。那么规则引擎是否具有这样类似的查询功能呢？或者我该如何去实现？

我对规则引擎的理念也很感兴趣，但是联想到实际的工作场景，我发现Drools并没有想象中的完美，以下疑问请教众位大侠：

1.规则里面很多的判据不是直接就具备的，需要一些整理过程，那么这些整理过程到底是在Java类里面做还是在Drools规则里面做？举例子说：
规则如下：
如果用户购买的商品中有两个以上的A产品和一个B产品就打85折。
如果用户购买的商品中有两个以上的B产品，就打8折。

在实际开发中，我们会把用户准备购买的产品都放在一个列表中。
如果要应用规则引擎，直接以产品列表为“事实”是最理想的，但是以直接以产品列表为“事实”就需要在规则中插入Java代码，用来整理出产品A和产品B的数量。这样一来，整理产品列表的Java代码就脱离了Java的运行环境，调试起来比较困难。至于更复杂的一些业务规则，用Rule去实现岂不是很难阅读和理解？

如果我们不直接以产品列表为"事实"，而已采购的产品A和B的数量为事实，那么在调用规则之前，就要在Java中整理产品列表，求出产品A和B的数量，然后将其作为“事实”调用规则。此种方案的缺点就是不够灵活。一旦规则变化了，需要纳入产品C的数量来作为打折的依据，那么既要修改Java中整理产品列表的代码，又要修改规则文件。这也是我们不愿意看到的场面！

没有用过Drools，但前公司（刚失业）用得很多（自己开发的商业规则引擎）。 我先讲一下它有的功能。
1.  规则引擎 理论上是给BA用的， 而不是给开发人员用的。（现实是BA基本上复杂一点的规则就写不出来了，但开发人员写的Rules BA必须能看懂。）
2.规则引擎能接受输入。我们的系统实现是：
建立一个巨大无比的树Domain Object， 里面有所有的信息。每一条Rules By Default 都有Access到Domain Object。
提供图形化的Column Picker。 应该说规则引擎跟你的Data Model是紧紧的结合在一起的。
Rule 应该有steps。前一个Step的值可以传到下一个Step。提供API调用Java。提供Rule 的调试工具。


2.所谓的“业务规则”和“业务逻辑”区别到底在哪？是不是所有业务逻辑都可以看做是“业务规则”？如果是这样，那么复杂的业务逻辑或者说复杂的业务规则用规则文件去编写是否合适？如何把握将哪些业务规则用规则引擎去实现的度？

基本上大部分的业务逻辑都可以看做是“业务规则”。其实越复杂的业务逻辑越应该用用规则文件去编写，（前提）因为BA是可以看得懂Rule的，如果我们把业务逻辑放到Java里面，只能通过测试才知道是否符合要求，但复杂的业务逻辑有很多时候很多地方Test Case 没有Cover。

3. 如果要推入工作内存的事实量较大，或者需要用到的规则量较大，规则引擎的性能可否满足要求呢？
取决于规则引擎的实现方式。

4. “部门经理（角色）能够批准2天以内的请假，总经理（角色）可以批准2天以上的请假”，这样的规则算不算业务规则？这样的规则中，什么是事实，什么是结论？在工作流的场景下，我期望的是给出申请的请假天数，然后根据业务规则找出可以批准的角色，然后将工作任务发给该角色。那么规则引擎是否具有这样类似的查询功能呢？或者我该如何去实现？

肯定算业务规则。不过你的例子不是很完善， 例如部门经理不应该能够批准自己的请假，所有给出申请的请假天数，然后根据业务规则找出可以批准的角色不是很合理。
应该是：定义好员工之间的关系。每一个员工根据不同的请求都有一个default NextAppover（当default NextAppover 请假了或者出差了怎么办太复杂了，讲不完）。default NextAppover 是根据条件不同而不同的。例如你要请假，你的default NextAppover 是谁，或者你要审批某一样东西default NextAppover 是不同的。所以default NextAppover本身应该由Rule决定。决定了NextAppover，再根据user请假的天数决定NextAppover是否有权批准，如果没有，通常由NextAppover决定下一步怎么办，通常是Pass 到他自己的NextAppover。 在你的例子中，假如是普通员工请假三天，你是否想直接找到总经理，然后把工作任务发给总经理而部门经理不知道呢？更复杂一点的例子是：如果你要请假，哪些人你是要CC的。
一些使用规则引擎必须要注意的问题：
那些Rule需要Versioning， 就是说不同的时间用不同Rule。哪些不要。
Rule 的命名和查找？
Rule 如何能够重复使用？（把十条Rule的逻辑放到一条里可能比Java Extract 一个方法难很多）。

我对规则引擎的理念也很感兴趣，但是联想到实际的工作场景，我发现Drools并没有想象中的完美，以下疑问请教众位大侠：

1.规则里面很多的判据不是直接就具备的，需要一些整理过程，那么这些整理过程到底是在Java类里面做还是在Drools规则里面做？举例子说：
规则如下：
如果用户购买的商品中有两个以上的A产品和一个B产品就打85折。
如果用户购买的商品中有两个以上的B产品，就打8折。

在实际开发中，我们会把用户准备购买的产品都放在一个列表中。
如果要应用规则引擎，直接以产品列表为“事实”是最理想的，但是以直接以产品列表为“事实”就需要在规则中插入Java代码，用来整理出产品A和产品B的数量。这样一来，整理产品列表的Java代码就脱离了Java的运行环境，调试起来比较困难。至于更复杂的一些业务规则，用Rule去实现岂不是很难阅读和理解？

如果我们不直接以产品列表为"事实"，而已采购的产品A和B的数量为事实，那么在调用规则之前，就要在Java中整理产品列表，求出产品A和B的数量，然后将其作为“事实”调用规则。此种方案的缺点就是不够灵活。一旦规则变化了，需要纳入产品C的数量来作为打折的依据，那么既要修改Java中整理产品列表的代码，又要修改规则文件。这也是我们不愿意看到的场面！

2.所谓的“业务规则”和“业务逻辑”区别到底在哪？是不是所有业务逻辑都可以看做是“业务规则”？如果是这样，那么复杂的业务逻辑或者说复杂的业务规则用规则文件去编写是否合适？如何把握将哪些业务规则用规则引擎去实现的度？


3. 如果要推入工作内存的事实量较大，或者需要用到的规则量较大，规则引擎的性能可否满足要求呢？

4. “部门经理（角色）能够批准2天以内的请假，总经理（角色）可以批准2天以上的请假”，这样的规则算不算业务规则？这样的规则中，什么是事实，什么是结论？在工作流的场景下，我期望的是给出申请的请假天数，然后根据业务规则找出可以批准的角色，然后将工作任务发给该角色。那么规则引擎是否具有这样类似的查询功能呢？或者我该如何去实现？