blocks|key|1702259|text|我所见过的规则引擎的最大优点是，它让业务规则所有者实现业务规则，而不是将责任推给程序员。即使您有一个敏捷流程，您不断地从涉众那里获得反馈并经历快速迭代，它仍然不会达到通过让制定业务规则的人实现它们所能达到的效率水平。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1702260|此外，如果规则嵌入在代码中，那么在删除简单规则更改可能导致的重新编译-重新测试-重新部署循环时，您也不能低估其价值。通常有几个团队参与到构建中，使用规则引擎可以使大部分工作变得不必要。|1702261|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The biggest pro that I've seen for rules engines is that it lets the Business Rule owners implement the business rules, instead of putting the onus on programmers. Even if you have an agile process where you are constantly getting feedback from stakeholders and going through rapid iterations, it's still not going to achieve the level of efficiency that can be achieved by having the people making the business rules implement them as well.

Also, you can't under-emphasize the value in removing the recompile-retest-redeploy cycle that can result from a simple rule change, if the rules are embedded in code. There are often several teams that are involved in putting the blessing on a build, and using a Rules Engine can make much of that unnecessary.

blocks|key|1487248|text|在某些情况下，规则引擎可以提供很多价值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487249|首先，许多规则引擎以更具声明性的方式工作。一个非常粗糙的例子是AWK，您可以将正则表达式分配给代码块。当文件扫描器看到正则表达式时，将执行该代码块。|1487250|您可以看到，在这种情况下，如果您有一个很大的AWK文件，并且您想要添加另一个“规则”，您可以很容易地转到文件的底部，添加您的正则表达式和逻辑，并完成它。具体地说，对于许多应用程序，您并不特别关心其他规则在做什么，并且这些规则并不真正相互操作。|1487251|因此，AWK文件变得更像“规则汤”。这种“规则汤”的性质让人们非常专注于他们的领域，而几乎不关心系统中可能存在的所有其他规则。|1487252|例如，Frank对总额超过1000美元的订单感兴趣，因此他将感兴趣的规则系统放入其中。“如果order.total+>+1000，那么给弗兰克发邮件”。|1487253|同时，萨利想要所有来自西海岸的订单："IF+order.source+==+'WEST_COAST‘THEN+email+Sally“。|1487254|因此，您可以在这个微不足道的人为设计的案例中看到，一个订单可以满足两个规则，但两个规则彼此独立。西海岸1200美元的订单通知了弗兰克和萨利。当弗兰克不再担心的时候，他会干脆把他的规则从汤里拉出来。|1487255|在许多情况下，这种灵活性可能非常强大。它也可以像本例一样，以简单的规则向最终用户公开。使用高级表达式，也许还可以使用轻量级脚本。|1487256|现在，很明显，在一个复杂的系统中，可能会发生各种各样的相互关系，这就是为什么整个系统不是“用规则完成的”。有人，某处将负责规则，而不是失控。但这并不一定会降低这样一个系统所能提供的价值。|1487257|请注意，这甚至不适用于专家系统，在专家系统中，规则在规则可以创建的数据上触发，而是一个更简单的规则系统。|1487258|无论如何，我希望这个例子展示了规则系统如何帮助扩充一个更大的应用程序。|1487259|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|16|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|17|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|W|$]]

Rule Engines can offer a lot of value, in certain instances.

First, many rule engines work in a more declarative way. A very crude example would be AWK, where you can assign regexes to blocks of code. When the regex is seen by the file scanner, the block of code is executed. 

You can see that in this case, if you had, say, a large AWK file and you wanted to add Yet Another "rule", you can readily go to the bottom of the file, add you regex and logic, and be done with it. Specifically, for many applications, you're not particularly concerned with what the other rules are doing, and the rules don't really interoperate with each other.

Thus the AWK file becomes more like a "rule soup". This "rule soup" nature lets folks focus very tightly on their domain with little concern for all of the other rules that may be in the system.

For example, Frank is interested in orders with a total of more than $1000, so he puts in to the rule system that he's interested. "IF order.total > 1000 THEN email Frank".

Meanwhile, Sally wants all orders from the west coast: "IF order.source == 'WEST_COAST' THEN email Sally".

So, you can see in this trivial, contrived case, that an order can satisfy both rules, yet both rules are independent of each other. A $1200 order from the West Coast notifies both Frank and Sally. When Frank is no longer concerned, he'll simply yank his rule out from the soup.

For many situations, this flexibility can be very powerful. It can also, like this case, be exposed to end users for simple rules. Using high level expressions and perhaps lightweight scripting.

Now, clearly, in a complicated system there are all sorts of interrelationships that can happen, an this is why the entire system is not "Done with rules". Someone, somewhere is going to be in charge of the rules not getting out of hand. But that doesn't necessarily lessen the value such a system can provide.

Mind this doesn't even go in to things like expert systems, where rules fire on data that rules can create, but a simpler rules system.

Anyway, I hope this example shows how a rules system can help augment a larger application.

blocks|key|1487305|text|它(和其他所有东西一样)取决于您的应用程序。对于一些应用程序(通常是那些永远不变的应用程序，或者规则最适合现实生活中的常量，也就是说，在很长一段时间内不会有明显的变化，例如物理属性和公式)，使用规则引擎没有意义，它只会带来额外的复杂性，并要求开发人员拥有更大的技能集。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487306|对于其他应用程序来说，这真的是一个好主意。以订单处理为例(订单是从开具发票到处理货币交易的任何东西)，不时会有一些相关的法律或法规(在司法意义上)发生微小的变化，要求您满足新的要求(例如销售税，经典)。与其试图强迫您的旧应用程序进入这种突然不得不考虑销售税的新情况，而不是像以前一样考虑销售税，调整您的规则集比不得不干预潜在的大量代码集更容易。|1487307|然后，您当地政府的下一个修正案要求报告特定标准内的所有销售，而不是您必须进入并添加这些。最终，你会得到非常复杂的代码，当你想要恢复其中一个规则的效果，而不影响所有其他规则时，这些代码将被证明是非常难以管理的。|1487308|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It (as everything else) depends on your application. For some applications (usually the ones that never change or the rules are best on real life constants, i.e. won't change noticeably in eons, for instance physical properties and formulae) it doesn't make sense to use a rule engine, it just introduces additional complexity and requires the developer to have a larger skill set.

For other applications it's really a good idea. Take for instance order processing (orders being anything from invoicing to processing currency transactions), every now and then there's a minute change to some relevant law or code (in the judicial sense) that requires you to fulfil a new requirement (for instance sales tax, a classic).
Rather than trying to force your old application into this new situation where all the sudden you have to think about sales tax, where as before you didn't, it is easier to adapt your rule set rather than having to meddle about in potentially a large set of your code.

Then the next amendment from your local government requires reporting of all sales within a certain criteria, rather than you have to go in and add that, too. In the end you'll end up with very complex code that will prove pretty difficult to manage when you turn around and want to revert effect of one of the rules, without influencing all the others...

blocks|key|1702403|text|到目前为止，每个人都对规则引擎持积极态度，但我建议读者要小心。当问题变得有点复杂时，您可能会突然发现整个规则引擎都不合适，或者比更强大的语言复杂得多。此外，对于许多问题，规则引擎将不能轻松地检测到极大地减少评估条件的运行时间和内存占用的属性。与依赖注入框架或更动态的编程语言相比，我更喜欢规则引擎的情况相对较少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1702404|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Everybody thus far has been very positive about rules engines, but I advise the reader to be wary. When a problem becomes a little bit more complicated, you may suddenly find that an entire rules engine has been rendered unsuitable, or much more complicated than in a more powerful language. Also, for many problems, rules engines will not be able to easily detect properties that greatly reduce the runtime and memory footprint of evaluating the condition. There are relatively few situations in which I would prefer a rule engine to a dependency injection framework or a more dynamic programming language.

blocks|key|1487396|text|“但说真的，有多少应用程序真的有这么多变化？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487397|老实说，我工作过的每个应用程序都经历了从概念到部署之后的重大工作流程和/或逻辑变化。这是“维护”编程的首要原因……|1487398|现实情况是，您不能预先考虑所有事情，这就是敏捷流程的原因。此外，BA似乎总是遗漏了一些重要的东西，直到在测试中发现它。|1487399|规则引擎迫使您真正将业务逻辑与表示和存储分开。此外，如果使用正确的引擎，您的BA可以根据需要添加和删除逻辑。正如克里斯·马拉斯蒂-格奥尔格所说，这让英国航空公司承担了责任。但更重要的是，它让广管局得到他们所要求的东西。|1487400|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

"but really, how many apps really have that many changes?"

Honestly, every app I have worked on has gone through serious workflow and/or logic changes from concept until well after deployment. It's the number one reason for "maintenance" programming...

The reality is that you can't think of everything up front, hence the reason for Agile processes. Further, the BA's always seem to miss something vital until it's found in testing.

Rule Engines force you to truly separate business logic from presentation and storage. Further, if using the right engine, your BA's can add and remove logic as necessary. As Chris Marasti-Georg said, it puts the onus on the BA. But more than that, it allows the BA to get exactly what they are asking for.

blocks|key|1487448|text|我见过的大多数规则引擎都被系统代码视为黑盒。如果我要构建一个域模型，我可能希望某些业务规则是该域模型的固有规则，例如，当对象具有无效值时告诉我的业务规则。这允许多个系统在不复制业务逻辑的情况下共享域模型。我可以让每个系统使用相同的规则服务来验证域模型，但这似乎会削弱我的域模型(正如问题中所指出的)。为什么？因为我并不是一直在所有系统上一致地实施我的业务规则，而是依靠系统程序员来确定何时应该实施业务规则(通过调用规则服务)。如果域模型完全填充，这可能不是问题，但如果您处理的用户界面或系统在其生命周期中更改域模型中的值，则可能会出现问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487449|还有另一类业务规则:决策制定。例如，保险公司可能需要对承保申请人的风险进行分类，并得出保费。您可以将这些类型的业务规则放在您的域模型中，但是通常需要针对此类场景的集中式决策，而且实际上，它非常适合面向服务的体系结构。这确实提出了一个问题，为什么是规则引擎而不是系统代码。规则引擎可能是更好的选择，因为业务规则负责决策随着时间的推移而变化(正如其他一些答案所指出的那样)。|1487450|规则引擎通常允许您在不重新启动系统或部署新的可执行代码的情况下更改规则(无论您从供应商那里得到了什么承诺，请确保您在非生产环境中测试您的更改，因为即使规则引擎是完美的，人类仍然会更改规则)。如果您在想，“我可以通过使用数据库存储更改的值来做到这一点”，那么您是对的。规则引擎不是做新事情的魔盒。它旨在成为一个提供更高抽象级别的工具，这样您就可以更少地专注于重新发明轮子。许多供应商更进一步，允许您创建模板，以便业务用户可以填写空白，而不是学习规则语言。|1487451|关于模板的一个告别警告:模板永远不会比编写没有模板的规则花费的时间更少，因为模板必须至少描述规则。计划更高的初始成本(就像您要构建一个使用数据库存储更改的值的系统，而不是直接在系统代码中写入规则一样)-+ROI是因为您节省了将来对系统代码的维护。|1487452|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Most rule engines that I have seen are viewed as a black box by system code. If I were to build a domain model, I would probably want certain business rules to be intrinsic to the domain model, e.g. business rules that tell me when an object has invalid values. This allows multiple systems to share the domain model without duplicating business logic. I could have each system use the same rule service to validate my domain model, but this appears to weaken my domain model (as was pointed out in the question). Why? Because instead of consistently enforcing my business rules across all systems at all times, I am relying on system programmers to determine when the business rules should be enforced (by calling the rule service). This may not be a problem if the domain model comes to you completely populated, but can be problematic if you're dealing with a user interface or system that changes values in the domain model over its lifetime.

There is another class of business rules: decision making. For example, an insurance company may need to classify the risk of underwriting an applicant and arrive at a premium. You could place these types of business rules in your domain model, but a centralized decision for scenarios like this are usually desirable and, actually, fit quite well into a service-oriented architecture. This does beg the question of why a rule engine and not system code. The place where a rule engine may be a better choice is where business rules responsible for the decision change over time (as some other answers have pointed out).

Rule engines usually allow you to change rules without restarting your system or deploying new executable code (regardless of what promises you receive from a vendor, do make sure you test your changes in a non-production environment because, even if the rule engine is flawless, humans are still changing the rules). If you're thinking, "I can do that by using a database to store values that change", you're right. A rule engine is not a magical box that does something new . It is intended to be a tool that provides a higher level of abstraction so you can focus less on reinventing the wheel. Many vendors take this a step further by letting you create templates so that business users can fill in the blanks instead of learning a rule language. 

One parting caution about templates: templates can never take less time than writing a rule without a template because the template must, at the bare minimum, describe the rule. Plan for a higher initial cost (the same as if you were to build a system that used a database to store values that change vs. writing the rules in directly in system code) - the ROI is because you save on future maintenance of system code.

blocks|key|1487495|text|在可配置的应用程序中，如果可以避免，您不想进行自定义构建，则规则引擎是一种优势。它们还擅长集中大型规则库，而像Rete这样的算法对于快速匹配大型规则集是有效的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1487496|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Rete_algorithm^0|1J|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

A rules engine is a win on a configurable application where you don't want to have to do custom builds if it can be avoided. They are also good at centralising large bases of rules and algorithms like <a href="http://en.wikipedia.org/wiki/Rete_algorithm" rel="nofollow noreferrer">Rete</a> are efficient for quickly matching against large rule sets.

blocks|key|1702615|text|我认为您对贫血域模型的担忧是合理的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1702616|我见过在我工作的生产环境中运行的两个著名商业Rete规则引擎的应用程序。我认为其中一个是成功的，另一个是失败的。|1702617|成功的应用程序是一个决策树应用程序，由大约10棵树组成，每棵树有大约30个分支点。规则引擎有一个允许业务人员维护规则的UI。|1702618|不太成功的应用程序有大约3000条规则被添加到规则数据库中。没有人知道添加新规则时是否存在冲突规则。人们对Rete算法知之甚少，而且该产品的专业知识已经离开了公司，因此它成了一个不可触及和不可重构的黑匣子。部署周期仍然受规则更改的影响-当规则更改时，必须执行完整的回归测试。记忆力也是一个问题。|1702619|我会轻装上阵。当规则集的大小适中时，就很容易理解更改，比如上面给出的简单的电子邮件示例。一旦规则的数量攀升到数百条，我认为您可能会遇到问题。|1702620|我还担心规则引擎会成为应用程序中的单例瓶颈。|1702621|我不认为使用对象作为划分规则引擎空间的一种方式有什么错。在遵循私有规则引擎的对象中嵌入行为对我来说似乎没问题。当规则引擎需要的状态不是其对象的一部分才能正确触发时，问题就会出现。但这只是设计困难的另一个例子。|1702622|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I think your concerns about anemic domain models are valid.

I've seen two applications of a well-known commercial Rete rules engine running in production where I work. I'd consider one a success and the other a failure.

The successful application is a decision tree app, consisting of ~10 trees of ~30 branch points each. The rules engine has a UI that does allow business folks to maintain the rules.

The less successful application has ~3000 rules slammed into a rules database. No one has any idea if there are conflicting rules when a new one is added. There is little understanding of the Rete algorithm, and the expertise with the product has left the firm, so it's become a black box that's untouchable and unrefactorable. The deployment cycle is still affected by rules changes - a complete regression test must be done when rules are changed. Memory was an issue, too. 

I'd tread lightly. When a rule set is modest in size it's easy to understand changes, like the simplistic e-mail sample given above. Once the number of rules climbs into the hundreds I think you might have a problem. 

I'd also worry about a rules engine becoming a singleton bottleneck in your application.

I see nothing wrong with using objects as a way to partition that rules engine space. Embedding behavior in objects that defer to a private rules engine seems okay to me. Problems will hit you when the rules engine requires state that isn't part of its object to fire properly. But that's just another example of design being difficult.

I'm auditing a project that uses what is called a <a href="http://en.wikipedia.org/wiki/Business_rules_engine" rel="noreferrer">Rules Engine</a>. In short, it's a way to externalize business logic from application code. 

This concept is entirely new to me and I'm pretty skeptical about it. After hearing people talk about <a href="http://www.martinfowler.com/bliki/AnemicDomainModel.html" rel="noreferrer">Anemic Domain Models</a> for the past few years, I'm questioning the Rules Engine Approach. To me they seem like a great way to WEAKEN a domain model. For example say I'm doing a java webapp interacting with a Rules Engine. Then I decide I want to have an Android app based on the same domain. Unless I want the Android app to interact with the Rules Engine as well, I'm going to have to miss out on whatever business logic was already written. 

As I don't have any experience with them yet, just curiosity, I was interested to hear about the pros and cons are in using a Rules Engine? The only pro that I can think of is that you don't need to rebuild your entire Application just to change some business rule (but really, how many apps really have that many changes?). But using a Rules Engine to solve that problem kind of sounds to me like putting a band-aid over a shotgun wound. 

UPDATE - since writing this, the god himself, Martin Fowler, has <a href="http://martinfowler.com/bliki/RulesEngine.html" rel="noreferrer">blogged about using a Rules engine</a>.

Rules Engine - pros and cons

回归测试

数据库

Android

我正在审核一个使用所谓的的项目。简而言之，它是将业务逻辑从应用程序代码外部化的一种方法。这个概念对我来说是全新的，我对此持怀疑态度。在过去几年里听到人们谈论之后，我开始质疑规则引擎的方法。对我来说，它们似乎是弱化域模型的一个很好的方法。例如，假设我正在做一个与规则引擎交互的java webapp。然后我决定我想有一个基...

问规则引擎-正反两面
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问规则引擎-正反两面EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问规则引擎-正反两面
EN