Our everyday life is driven by rules. Every time we stop at a red light while driving, we do so as we're following a rule that says we should stop when the light turns red. We all also know the rule that states that when we are of a specific age, we are allowed to take a test to get a driving license.
Even if we don't follow these rules, like the daredevil developers we all are, we're still bound by the rules of nature; if you don't breathe in oxygen, you asphyxiate. If you jump, you're going to touch the ground eventually as the rules of physics determine that gravity will pull you down. Some of these rules (like gravity) have been studied so much that they can be expressed as simple mathematical equations. However, for our everyday rules that we consider common sense, we use a simpler structure: for a group of conditions that we detect, we take specific actions.
These sort of structures are very important for organizations as they have to deal increasingly with complex scenarios. These scenarios are composed of a large number of individual simple decisions, which work together to provide a complex evaluation of the full picture. This complex evaluation starts with simple assessments used to determine the nature of our environment that we will call inferences. These inferences might be crossed with other pieces of data or more inferences until a complex view of the domain can be achieved, understood, and actions can be taken for the benefit of the organization's goals.
These implied decisions were, for a long time, a part of the systems of an organization through very static structures. Starting with the mainframe applications, evolving over time as services, web applications, and middleware solutions, these solutions always had a high coupling with the rest of the system. business rules, on the other hand, allows for a specific, easy-to-read, and split structure to be used to define these decisions in a way that make sense to different groups in an organization—and not just the development areas—and can be quickly implemented and updated automatically.
Depending on the specific syntax of each rule engine, the syntax might vary a bit. Nonetheless, there are primal structures that are common to all the rule engines and they look something similar to the following:
when a condition is found to be true, then an action is executed
We can add as much syntax sugar on top of this as we can think of; however, this basic structure is what lies underneath it all: a list of conditions and actions. A condition is basically a constraint or filter. These filters will look at the information available in a domain to try and find data that meets the defined criteria. Once a group of data is obtained matching the condition, an action or consequence is scheduled to be executed, taking the matching data as a parameter.
A condition always works like a query; it narrows data from a specific domain by specific filters. This means that a rule will make sense in a specific domain: If your rules are designed to filter apples and the only data you feed these rules are oranges, the rules will never find their conditions to be true.
As simple as this structure might be, it is the basis of all the business rules that we will see in this book. Thanks to this structure, business rule systems provide a great advantage over the conventional code for defining complex scenarios. Over the next sections, we will explain these advantages.
The business rules are based on a programming paradigm called Declarative Programming. This paradigm sustains that you can express the logic of a program without having to explicitly describe the flow of instructions that must be followed. Since the condition works as a filter, whenever data is introduced to the rule engine that matches a condition, a rule or group of rules is determined to be executed.
This means that the control of the flow is neither determined by the order of the rules nor by the order of the incoming data, but by the conditions the rules declare. This declarative approach allows any number of rules to be written without having to worry about any specific place where they need to be written.
Imperative programming is the name we give to our everyday programming paradigm. This type of programming is used by languages such as Java, C#, Perl, and many others. It is defined by the control of the sequence flow of instructions, we explicitly inform when each code instruction should be executed.
The declarative approach, on the other hand, doesn't allow a direct control of the sequence flow to the developer, instead it lets the data guide the rule that should be executed. At first, this might seem hard to grasp or be considered as a useful trait for a language. However, we're about to see how Drools allows a very useful union between declarative implementations based on Drools rules and imperative implementations based on Java.
Of course, these Drools-based rules will have to be run on a Java application, where the sequence flow of the steps to be executed is determined by the code. In order to achieve this, the Drools rule engine transforms the business rules into execution trees, as shown in the following image:
As you can see in the preceding image, each rule condition is split in small blocks, connected and reused within a tree structure. Each time data is fed to the rule engine, it will be evaluated in a tree similar to this one and reach an action node, where they will be marked as data ready for executing a specific rule.
This transformation from business rules to execution tree is possible as the Business Rule structures are excellent for representing themselves as data. This means that the very code of the rules can be quickly transformed into very performing execution structures and also updated and changed during runtime. This happens because every condition can be easily added, moved, or deleted by changing the tree structure.
Tip
It is worth mentioning that, however, the previous image is just an example. The actual decision tree that is generated is a more complex topic, which we will cover in the following chapters. The previous image is just to show the objective of the decision tree.
In the next section, we will discuss the reasons these structures are very useful for performance, collaboration, and maintenance of complex systems.