The solution

The problem is that with an imperative-style language, we are implementing both: what needs to be done (business requirements) and how it needs to be done (algorithm). Let's look at declarative-style programming, for example, the SQL in relational databases. The SQL describes what we want to search; it doesn't say anything about how the database should find the data. This is exactly what we need for our business requirements.

A rule engine provides an alternative computation model. We declare rules in pretty much the same way as the business analyst does requirements, that is, as a group of if-then statements. The rule engine can then take these rules and execute them over our data in the most efficient way. Rules that have all their conditions true have their then part evaluated. This is different to imperative-style programming languages where the developer has to explicitly specify how it needs to be done (with sequence of conditionals and loops).

If we rewrite code from Code listing 1 in a declarative manner, it might look something like this:

if Customer( level == Level.Gold ) then do something else for Gold customer if Customer( level == Level.Silver ) and no Account( ) then do something for Silver customer who has no accounts if Customer( level == Level.Silver) and Account( balance < 0, customer.accounts contains account ) then do something for Silver Customer that has account with negative balance

Code listing 2: Rules from Code listing 1 written using declarative style

Each rule represents one requirement. This is more readable and maps to business requirements more naturally.

It is also useful to note that in an imperative program, the piece of code evaluating the customer's level in the first example needs to be explicitly invoked, passing to it a specific customer. In a declarative program you cannot invoke a given rule directly; do not decide on which data you want to run it, because the customer instance is actually taken from a working memory (this will be described later).

Advantages The following is a summary of the various advantages of a declarative-style solution that Drools brings: Easier to understand : Rules are easier to understand for a business analyst or a new developer than a program written in Java or other imperative-style language. It is more likely for a technically skilled business analyst to verify or change rules than a Java program.

Improved maintainability : Since rules are easier to understand, a developer can spend more time solving the actual problem.

Dealing with evolving complexity : It is much easier to add new, modify, or remove existing rules than to change, for example, a Java program. The impact this has on other rules is minimal in comparison with an imperative-style implementation.

Flexibility : It deals better with changes to the requirements or changes to the data model. Changing or rewriting an application is never an easy task. However, thanks to the formalism that rules bring, it is much easier to change rules than to change a Java program.

Reasonable performance : Thanks to the Rete algorithm that is behind Drools; in theory, the performance of the system doesn't depend on the number of rules. With every release of Drools, the performance of the engine is getting better by adding various optimizations such as Rete node sharing, node indexing, parallel execution, and so on. All this benefits new as well as old rules.

Translating requirements into rules : The representation of business rules is consistent. For example, let's take some business rule and implement it in Java. Developers, depending on their experience, tend to use different ways to solve a problem. We'll find out that the possible solutions will vary greatly. Whereas with rules, this diversification becomes less apparent. It is simply because we are expressing "what" instead of "how". As a result the code is much easier to read even by new developers.

Ability to apply enterprise management to our rules : This builds on the previous advantage of consistent representation. If we have consistent representation, it is much easier to introduce new features that apply across all our rules (for example, auditing, logging, reporting, or performance optimizations).

Reusability : The rules are kept in one place (separation of business logic from the rest of the system), which means easier reusability. For example, imagine you've written some validation rules for your application and later on there is a need to do some batch imports of data, so you could simply reuse the validation rules in your batch import application.

Modeling the application closely : Rules model the application invariants more closely. The imperative-style solutions tend to impose arbitrary and often unnecessary ordering on operations, depending on the algorithm chosen. This then hides the original invariants of the application.

Unifying : The Drools platform brings unification of rules and processes. It is easy to call rules from a process or vice versa.

Redeploying: It is possible to change/redeploy rules and processes without even stopping the whole application.