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 an a real world application or system, there are lots of challenge to manage these logic. And by manage we mean: defining, designing, implementing and executing them in the way that is more maintainable. If the logic of the application or system being maintained in a proper, systematic way it brings more value to the project.
In system or application development, you can see these logic being spread in all over different layers, components and services. And most of the times they are shared conceptually but not physically, and that is a challenge.
Where do they live?
In a system with a standard tree layer architecture, these logic would be centralized in the middle layer generally. However this does not mean they do not need to be execute in different layers of application.
Sometimes to enforce these logic, the execute will be happening in different layers of application. For instance, when user is trying to submit a form, an initial check may happen in the UI layer then the request will be passed to business logic layer and then to the data access layer.
What is business rule?
Business rules are the rules that enforces the 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." from Wikipedia.
According to the white paper by the Business Rules Group, Defining Business Rules ~ What Are They Really?,  a 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 talk 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.
Business rules (including laws of nature) define how knowledge in one form may be transformed into other knowledge, possibly in a different form.
As an example of a business logic in a "Rentals" business context:
- Most rentals are 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 rules 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 uses them to continue its task. To cover all the scenarios that may be required for supporting different types of rules, FlexRule provides multiple different logic type. Which each of them can be used based on the types of the rule your application requires to deal with. Also it is possible that your application uses all of the different logic.