Rules Engine - Pros and Cons

Question

I am checking a project that uses the so-called Rules Engine . In short, this is a way to externalize business logic from application code.

This concept is completely new to me, and I am rather skeptical about it. After over the past few years, people talked about writing about using the rule engine .

Answer 1

Most of the rule engines that I have seen are viewed by the system code as a black box. If I were to create a domain model, I would probably want certain business rules to be an integral part of the domain model, for example. business rules that tell me when an object has invalid values. This allows multiple systems to share a domain model without duplicating business logic. I could use the same rule service for each system to validate my domain model, but this seems to weaken my domain model (as mentioned in the question). What for? Because instead of constantly applying my business rules to all systems at all times, I rely on system programmers to determine when business rules should be followed (by calling the rule service). This may not be a problem if the domain model suits you fully filled, but it can be problematic if you are dealing with a user interface or a system that changes the values ​​in the domain model during its existence.

There is another class of business rules: decision making. For example, an insurance company may need to classify an applicant's underwriting risk and receive a premium. You can place these types of business rules in your domain model, but a centralized solution for such scenarios is usually desirable and, in fact, fits well with a service-oriented architecture. This begs the question of why the rule engine is not the system code. The place where the rule engine may be the best choice is when the business rules responsible for making the decision change over time (as some other answers pointed out).

Rules mechanisms usually allow you to change rules without restarting the system or deploying new executable code (no matter what promises you get from the vendor, make sure you check your changes in a non-production environment, because even if the rules mechanism is perfect, people still change regulations). If you think, “I can do this using a database to store values ​​that change,” you are right. A rule engine is not a magic box that does something new. It is designed to be a tool that provides a higher level of abstraction, so you can focus on reusing the wheel. Many vendors take this even further by allowing them to create templates so that business users can fill in the blanks rather than learn the rules language.

One caveat to patterns: patterns can never take less time than writing a rule without a pattern, because a pattern should at least describe a rule. Plan for a higher initial cost (just as if you were building a system that used a database to store values ​​that change or write rules directly in the system code) - the return on investment is that you save the future maintenance of the system code.

Answer 2

I think your concerns about anemic domain models are valid.

I saw two applications of the well-known commercial Rete rule engine that works in the production where I work. I consider success successful and the other unsuccessful.

A successful application is a decision tree application consisting of ~ 10 trees with 30 branch points. The rules engine has a user interface that allows business people to support the rules.

The less successful application has ~ 3,000 rules slammed into the rule database. No one knows if there are conflicting rules when adding a new one. There is little understanding of the Rete algorithm, and experience with the product has left the company, so it becomes a black box, untouchable and unresponsive. Rule changes still affect the deployment cycle - a full regression test should be performed when the rules change. Memory was also a problem.

I would do a little. When a rule set is modest in size, it easily understands changes, such as the simplified email example above. As soon as the number of rules reaches hundreds, I think you may have a problem.

I also worry about the rule engine becoming a bottleneck in your application.

I do not see anything wrong with using objects as a separation method that manages machine space. Embedding behavior in objects that are deferred to the mechanism of private rules seems acceptable to me. Problems hit you when the rule engine requires a state that is not part of its object in order to function normally. But this is just another design example, complex.

Answer 3

Rule Engines can offer great value in certain cases.

First, many rule engines work more declaratively. A very crude example would be AWK, where you can assign regular expressions to blocks of code. When a regular expression is examined by a file scanner, a code block is executed.

You can see that in this case, if you had, say, a large AWK file, and you wanted to add another "rule", you can easily go to the bottom of the file, add a regular expression and logic, and you need to end it . In particular, for many applications, you don’t really care about what other rules do, and the rules do not actually interact with each other.

Thus, the AWK file is more like a rule soup. This “soup soup” allows people to concentrate very strongly on their domain without worrying about all the other rules that may be in the system.

For example, Frank is interested in orders worth more than $ 1,000, so he inserts into the system of rules that interests him. "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, far-fetched case that order can satisfy both rules, but both rules are independent of each other. An order of $ 1,200 from the West Coast notifies Frank and Sally. When Frank is no longer bothered, he will simply endure his exclusion from the soup.

For many situations, this flexibility can be very powerful. It can also, like this case, be available to end users for simple rules. Using high-level expressions and possibly an easy script.

Now, it is obvious that in a complex system there are all sorts of interconnections that can occur, so the whole system is not "executed with rules." Someone, somewhere, will be responsible for the rules that do not go out of control. But this does not necessarily reduce the value that such a system can provide.

Remember that this is not even included in things like expert systems, where rules trigger data that rules can create, but a simpler system of rules.

In any case, I hope this example shows how a rule system can help increase a larger application.

Answer 4

The biggest professional I've seen for rule engines is that it allows business rule owners to implement business rules instead of putting onus on programmers. Even if you have a flexible process, when you constantly get feedback from interested parties and go through fast iterations, it still will not reach the level of efficiency that can be achieved due to the fact that people also implement business rules.

In addition, you cannot underestimate the value of removing the recompile-re-deploy cycle, which may be the result of a simple rule change if the rules are embedded in the code. Often there are several teams that participate in the blessing of the assembly, and using the rule engine may make much of this unnecessary.

Answer 5

I wrote a rule mechanism for a client. The biggest victory was all concerned. The engine can start (or play) the request and explain what is happening in the text. Business people can look at the text description and quickly indicate the nuances in the rules, exceptions and other special cases. When the business side was involved, validation got a lot better because it was easy to get their input. In addition, the rules engine can live separately from other parts of the application code base, so you can use it in different applications.

Kon, that some programmers don't like to learn a lot. The rules mechanisms and rules that you insert into them, along with the material that implements them, can be a little hairy. Although a good system can easily handle sick and twisted logic networks (or often illogical), it's not as simple as coding a lot of if (regardless of what some of the simple rule engines do). The rules engine provides you with tools for handling rule relationships, but you should still be able to present all of this in your mind. Sometimes he likes to live in the movie Brazil. :)

Answer 6

This (like everything else) depends on your application. For some applications (usually those that never change or the rules are best suited for real-life constants, i.e. will not noticeably change into eons, for example physical properties and formulas), it makes no sense to use the rules mechanism, it just introduces an additional complexity and requires the developer a larger set of skills.

For other applications, this is a really good idea. Take, for example, order processing (orders are some kind of invoicing for processing foreign exchange transactions), from time to time there will be a slight change in any relevant law or code (in the judicial sense) that requires you to fulfill a new requirement ( e.g. sales tax, classic). Instead of trying to force your old application to enter this new situation, when suddenly you have to think about sales taxes, where, as before, there isn’t, it’s easier to adapt your set of rules, rather than interfere with a potentially large set of your code.

Then the next amendment from your local government requires reporting on all sales according to certain criteria, and you will not have to go in and add this too. In the end, you will get very complex code that will be quite difficult to handle when you turn around and want to return the effect of one of the rules without affecting everyone else ...

Answer 7

So far, everyone has been very positive about rule engines, but I advise the reader to be careful. When a problem becomes a little more complicated, you may suddenly find that the whole mechanism of the rules turned out to be unusable or much more complicated than in a more powerful language. In addition, for many problems, rule engines will not be able to easily detect properties that significantly reduce the execution time and memory size for evaluating the state. There are relatively few situations in which I would prefer the rule engine to be based on a dependency injection platform or a more dynamic programming language.

Answer 8

"but really, how many applications really have a lot of changes?"

Honestly, every application I worked on experienced a serious workflow and / or logical changes from concept to needed after deployment. This is the main reason for programming "maintenance" ...

The reality is that you cannot think about everything ahead, hence the reason for Agile processes. In addition, BA always seems to have missed something vital until it showed up during testing.

Rule Engines force you to truly separate business logic from presentation and storage. In addition, if you use the right engine, your BA can add and remove logic as needed. As Chris Marasti-Georg said, this puts a burden on BA. But more than that, it allows BA to get exactly what they ask.

Answer 9

The rule engine is a win in a custom application in which you do not want to perform custom assemblies if this can be avoided. They also centralize well the large basics of rules and algorithms such as Rete are effective for quickly matching large sets of rules.

Answer 10

Already a lot of good answers, but I wanted to add a couple of things:

• when automating a solution of any complexity, a critical thing quickly becomes your ability to manage, rather than execute, the logic involved. The rule engine will not help in this - you need to think about the rule management capabilities that the business rule management system has. Most commercial and open source engines have evolved into rule management systems with repositories, rule usage reports, version control, etc. A rule repository, structured into consistent sets of rules that can be organized to make business decisions, is much easier to manage than thousands of lines of code or a soup rule.
• There are many ways to use a declarative, rule-based approach. Using rules to control the user interface or as part of the determination process can be very effective. However, the most valuable use of the rule approach is the automation of business decisions and providing this as loosely coupled decisions that take input, execute rules, and return a response — a decision. This refers to services that answer questions from other services such as "is this customer a good credit risk" or "what discount should I give this customer for this order" or "what is the best cross selling for this customer at this time. These solutions may be built very efficiently using a rule management system and make it easy to integrate analytics over time, which will benefit many decisions.

Answer 11

I see that the mechanisms for managing rules, processes and data (aka databases) are essentially similar. But for some reason, we never say that the black copy of the save subsystem is bad.

Secondly, from my POV, the anemic model is not something that is easy to implement , it is easy to use. The actual method that describes the available behavior in the domain model object should not be executed by the object itself.

Answer 12

The biggest difficulty of my experience at Rule Engines is this:

• from OOP POV is a real pain for refactoring and testing rules written in a declarative language, while you are refactoring code that affects them.
• Often we always have to think about the order of the rules, which turns into a mess when there are a lot of them.
• Some minor changes may cause incorrect behavior of the rules leading to production errors. In practice, it is not always possible to cover all test cases in front.
• Rules that modify objects used in others also add complexity, forcing developers to break them down into stages.