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:
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:
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.
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:
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:
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.
52.15.129.90