When should we use rules?

The business rules are very powerful components. They introduce a large number of changes in the way we define our business logic. They allow us to handle the complexity, performance, and maintenance of our systems in order to accomplish a lot in a very little time.

These improvements are of great value for any project and business rules can be implemented and added to any type of project that you might find out there. Nonetheless, we want to remark these projects that would benefit the most on introducing business rules to their technological stack. These projects have one or more of the following characteristics:

• They define a very complex scenario that is difficult to fully define even for business experts
• They don't have a known or well-defined algorithmic solution
• They have volatile requirements and need to be updated very often
• They need to make decisions fast, usually based on partial amounts of data

Complex scenario, simple rules

Every once in a while, we find systems—or parts of systems—where small relations among components start having more importance the more we investigate them. At first, they might seem innocuous components that take very little decisions based on small relations between two or three sources of data. As we start investigating them further, these relations take on more and more importance. Eventually, we might find the relationship between the parts produces more collective behaviors that even the business experts were unaware could happen; however, this still make sense. These kinds of systems are called Complex Systems and they are one of the places where business rules provides a great aid.

Complex scenarios are usually defined by small statements. The full picture, involving every single composition, aggregation or abstraction of data needed to completely define the scenario, is usually something beyond our initial grasp. Therefore, it is common that such systems start being defined through partial explanations. Each small relation in the system gets defined as a different requirement. When we analyze each one of these requirements, on splitting them into their most basic elements, we find ourselves defining business rules.

Each Business Rule helps in defining every small component of a complex scenario. As more and more rules are added to the system, more and more of these relations can be handled in a simple-to-read way. Each rule then becomes a self-explanatory manual for each small decision that the system takes when executing our complex scenario.

The examples of complex applications can be very varied, as follows:

• Fraud detection systems: Usually they take information from every transaction done within a central service and investigate the correlations between them to determine situations that are unlikely to come from an honest and legal use of the system. Things such as unusual credit card operations, large amounts of activity in usually stable accounts, and unexpected parameters in transactions are usually the things searched by these systems.
• Customized retail coupons for returning clients: In all kinds of commercial activities, client fidelity is always valued. A usual strategy to maximize it is through special coupon generation based on the client's shopping habits. To accomplish the right coupon, a complex system needs to evaluate the purchase history of the client, frame the client in a specific demographic subgroup, and select the best offer available for this subgroup. All these things need to be done based on the complex relations between different purchases and their tendencies.
• Credit scoring software: Credit scoring is a numerical expression based on a level analysis of a person's credit files to represent the person's credit worth. Every debt, credit, purchase, or relation can be a valid source of data to determine the scoring of a person. The complexity of this scenario comes from having to correlate, weigh, and return a specific score for a person based on the correlation of all these sources of data.

Ever-changing scenarios

Even when we don't have a complex scenario in our hands, we might still benefit a great deal from defining our application's logic using business rules. If the elements involved in making a particular decision tend to change very frequently, business rules can be a good solution for managing such volatility in the behaviour of a system.

The business rules are represented in the rule engine as a data tree. In the same way that we can modify the elements of a list, we can remove or add a Business Rule from a rule engine. This can be achieved without having to restart our application or reinstalling any components. Internal mechanisms provided by the Drools 6 framework can be used to update the rule definitions automatically from external sources. The tooling provided by Drools 6 is also prepared to provide update mechanisms for the business rules from user-friendly editors. The complete architecture of the Drools 6 API is based on making this as adaptive as possible.

If we find a system where the requirements might change very frequently, even in a daily or hourly frequency, business rules may be the best fit for such requirements due to its update capabilities, regardless of the complexity of the system.

Example–eShop system

Along the rest of the book, we will work on a set of decision services based on business rules with a common domain: an eShop application. Practise is a crucial component of learning about a new framework and in order to make it simple in order to go into detail on the rule engine as fast as possible, we will define a basic model shared between most of our examples.

To start with, we will define the model of our eShop system. This model will contain all the different things that are relevant to make decisions about our application. Some of these objects are as shown in the following:

• Product: Our shop will sell different kinds of items. Each kind will be represented by a product object, containing the details about the specific item.
• Stock: This is the amount of each product that we have in storage.
• Provider: Our products come from different providers. Each one of them can provide the eShop with specific kinds of products in a specific capacity for delivery.
• Provider Request: When we run low or out of a specific product, we will have to create a request for our providers to fill our stock.
• Client: The shop has clients that will have preferences for specific products, pending and completed orders, specific demographic information, payment preferences, and any type of data that we can obtain from their navigation on our eShop.
• Order: When a client likes one or more products in our eShop, they can order them to be delivered. The orders have different status, depending on whether the client received it successfully or not. They also have information about its specific products and their quantity.
• Discount: The eShop offers different types of discounts, depending on the type of purchase.
• Sales channel: The eShop that we will emulate can work with multiple sites and each one of them is treated as a different sales channel. Each sales channel will have its own specific target audience, which is determined by the clients who use it.

As we need more types of objects to define the reality of our eShop, we will define more classes to extend the understanding of our world. Once we start correlating all these pieces of domain data together, we will be able to detect all types of situations and act upon them in the benefit of both our eShop and its clients. Some of the things that we will be able to do are shown in the following:

• Defining the best sales channel for a specific kind of product by correlating products with each sales channel and comparing them with the rest of them. Based on this information, we can create custom discounts for the products in these channels.
• Defining the client preferences for specific products. Based on this information, we can offer them discount tickets tailored for their specific tastes.
• Determine the average consumption of specific products and compare them with our stock. In case of necessity, we can automatically trigger provider requests.
• Based on how many orders we have in process for specific providers, we can ask for a discount on the price.
• We can analyze the different purchases that our clients make in our eShops. If, at some point, the purchases go beyond what we consider normal, we can take a series of actions, from a simple warning to providing direct human support for a specific purchase.

These are just a few things that we could do with business rules for such domains. As we find more situations with specific requirements to be fulfilled, we will learn new techniques to write our rules and configure our runtime. Each new necessity will guide us to define new components in order to get the most out of the Drools 6 framework.