Why should I use Drools?

Ryan Jolly Young
Jan 25, 2017 · 5 min read

The first thing I should mention, is that Drools, or any rule engine for that matter, are not necessary in every application. A rules engine may be a hammer, but not every system is a nail. There is a large amount of overhead used in a rules engine, that you don’t get with hard coded business logic. There is also a fair bit of complexity behind learning a new technology like drools. We are going to look at a breakdown of what a system that needs a rule engine might look like.

Not every problem needs a hammer

The first criteria for a rules engine is probably the easiest one to point out, and that is that it needs rules. A system that needs a rules engine will have complex business logic. The easiest way to determine whether your system is complex or not is to try and write out some functionality in pseudocode. (If you can’t figure out the pseudocode for the logic in your application, chances are that it might not even work with a rules engine, however using a rules engine in a testing environment could help you determine what the logic in your program will look like.) If in your pseudocode, you have multiple nested if statements, complicated switches, or other “fiddly” conditional statements, then a rules engine might be a perfect fit. If your system is easily explained with pseudocode, then don’t over complicate it. Quit while you’re ahead.

This point is especially important if the business logic is going to exist in a highly fragile state.

So, you’ve determined that your system has complicated logic, now you need to determine if it’s going to change any time soon. If the business logic in this system isn’t going to change in the foreseeable future don’t bother trying to make it easy to change. The system doesn’t need the additional memory requirements, and it doesn’t need any complications.

The code is changing often, and it is pretty complicated logic, but does the company have business analysts or technical users who are capable of writing a business rule? Those technical users really let a rules engine shine, because with either a little training, or the use of a domain specific language(DSL) they can modify the business logic to their needs. DSL’s allow rules to be written in what is essentially regular language. Let’s look at an example:

rule “blue Cars”
$car : Car(colour==”blue”) then $car.setPremium($car.getPremium() + 25); endrule “theft” when $car : Car(price >=300, theftRating >=2) then $car.setPremium($car.getPremium() + 5000); End

Above are two rules that take information from a Car object in Java, and determine the insurance premium for that Car. Now I haven’t taught anything about the syntax of rules in these blog posts yet, so you are essentially about the level of understanding as a regular business user. The two rules above probably don’t make a ton of sense to you. Let’s look at how a DSL might fix this:

[condition][]If there is a “{colour}” car=$car : Car(colour==”{colour}”)[condition][]Price is at least {price} and theft rating is at least {theftRating}=$car : Car(price >={price}, theftRating >={theftRating})[consequence][]Set premium to {premium}=$car.setPremium($car.getPremium() + {premium});

Above is a DSL file that will take an input and translate it to regular rules. I’ll show you what the two templates we created looks like below:

//Template 1
rule "name"
If there is a "colour" car then Set premium to # end//Template 2
rule "name"
Price is at least # and theft rating is at least # then Set premium to # end

These templates allow almost anyone to create business rules that work for them. The rule that I displayed above can be created using the DSL we created and the following code:

rule “blue Cars”
If there is a “blue” car then Set premium to 25 endrule “theft” when Price is at least 300 and theft rating is at least 2 then Set premium to 5000 end

Not only does this allow non-technical users to create their own rules, but they can easily change preexisting code. It also can be written in such a way that anyone can understand it, and by extension be used as documentation for the system. Not only that, but each user can have their own independent rule base, allowing them to run tests on complicated data easily.

Now part of you might be freaking out. Putting power into the users’ hands is often a terrible idea. Even with the incredibly powerful algorithms running Drools, putting countless rules into it can grind this engine to a standstill. Like any environment, you need to be careful, and set standards to ensure that the rules being added to the system are useful, and necessary.

So, we have determined that at the very least your system needs complicated data, that will change often to implement a rules engine. If the users are tech savvy or properly regulated we can allow them to author their own rules, which allows for the business rules to be in the hands of the business users.

Let’s go over a couple other benefits that rule engines bring to a system:

  • Despite object-oriented programming’s habit of tightly coupling data and logic, rules engines separate them. When your implementing changes in your system, you wont have to worry about breaking your application logic. This is especially valuable when all of your rules are stored in one central location, and a complicated multi-domain program only has to look in one place.
  • Because all this information is in the same place, and is pretty easy to read, it can serve as decent documentation. This is even more apparent when the rules are built with DSL’s.
  • Lastly, we can use “Declarative Programming” (Declaring logic without mucking around with the order of the logic). This makes rules easy to follow, and can find solutions to incredibly difficult problems, while explaining exactly how the system got to that point.֑