◷ Reading Time: 4 minutes
According to Wikipedia: “Business logic, or domain logic, is a non-technical term generally used to describe the functional algorithms that handle information exchange between a database and a user interface.”
It sounds simple. However, in a real-world application or system, there are lots of challenges to managing this logic. By manage we mean: defining, designing, implementing and executing it in a way that is more easily maintained. If the logic of the application or system is being maintained in a proper, systematic way, it brings more value to the project.
In system or application development, you can see this logic being distributed all over different layers, components, and services. And most of the time it is shared conceptually but not physically, and that is a challenge.
Where does it live?
In a system with a standard tree layer architecture, this logic would usually be centralized in the middle layer. However, this does not mean it does not need to be executed in different layers of the application.
Sometimes, to enforce this logic, the execution will be happening in different layers of the application. For instance, when a user is trying to submit a form, an initial check may occur in the UI layer. Then the request will be passed to the business logic layer, and from there to the data access layer.
What is a business rule?
Business rules are rules that enforce business logic. “A business rule is a rule of a business, company, or corporation. It is a rule that defines or constrains some aspect of business and always resolves to either true or false.” (Wikipedia)
According to the white paper by the Business Rules Group, “Defining Business Rules ~ What Are They Really?” the statement of a business rule falls into one of four categories:
- Definitions of business terms
The most basic element of a business rule is the language used to express it. The very definition of a term is itself a business rule that describes how people think and talks about things. Thus, defining a term is establishing a category of business rule. Terms have traditionally been documented in a glossary or as entities in a conceptual model.
- Facts relating terms to each other
The nature or operating structure of an organization can be described in terms of the facts that relate terms to each other. To say that a customer can place an order is a business rule. Facts can be documented as natural language sentences or as relationships, attributes, and generalization structures in a graphical model.
- Constraints (also called “action assertions”)
Every enterprise constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. To prevent a record from being made is, in many cases, to prevent an action from taking place.
- Derivations
Business rules (including the laws of nature) define how knowledge in one form may be transformed into other knowledge, possibly in a different form.
Sample Rules
As an example of business logic in a “Rentals” business context:
- Most rentals are made by advance reservation.
- The rental period and the car group are specified at the time of reservation.
- EU-Rent also accepts immediate (‘walk-in’) rentals, if cars are available.
How can FlexRule help?
FlexRule is a framework containing API libraries, Designer, Tester and Debugger that helps you to model the rule and execute it inside your application or system. When the rule is designed in a high-level language (XML, S-Expression), then your application or system loads the rule model and executes it. After finishing the execution, your application can then collect the result and use it to continue its task. To cover all of the scenarios that may be required for supporting different types of rules, FlexRule provides multiple different logic types. Each of these can be used based on the type of rules your application requires. Also, it is possible that your application will use all of the different logic types.