Organize business rules based on rule systems

Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/06/30/55926.html

Update part of content 2007.12.20
In addition to the business flow description, the use case (User story) in the analysis stage is also an important part of business rules. There are different ways to organize and implement these business rules (which will bring different benefits ). In addition to the code implementation of traditional developers, more and more systems begin to use rule systems for organization.

There are two famous articles on the application rule engine Network: Java Rule Engine and Its API application details and business rule engine on the Enterprise Platform
In addition, JBoss also launched jbpm Based on drools. Oracle also launched its own rule product.

However, before applying the rule engine, you need to understand four issues:
The first question is: what is a business rule?
I thought the book "business rules applied" has a reasonable classification of business rule:
 

Constraint	A constraint can be a mandatory restriction or suggested restriction on the behavior of the business event. A mandatory constraint is a complete statement that expresses an unconditional circumstance that must be true or not true for the business event to complete with integrity. Examples of mandatory constraints are: A customer must not have more than 10 open orders at one time. The total dollar amount of a customer order must not be greater than the customer's single order credit limit amount.
Guideline	A guideline is a complete statement that expresses a warning about a circumstance that shoshould be true or not true. A guideline does not force the circumstance to be true or not true, but merely warns about it, allowing the human to make the demo. because a guideline only warns and does not reject, it provides a freedom of choice. an example of a guideline is: A customer shoshould not have more than 10 open orders at one time.
Action Enabler	A complete statement that tests conditions and upon finding them true, initiates another business event, message, or other activity. that is, an action enabler initiates a new action external to the scope of the system or increment under study. Examples of Action enablers are: If a customer order is valid, then initiate the place order process. If a customer is high risk, then has y the Customer Services Manager. Action-enabler rules can be used in some databases cial rules products to create an event-oriented sequence of workflow steps. it may be helpful to think of mandatory constraints and action enablers as opposites. mandatory constraints stop an event from completing. action enablers start an event.
Computation	A complete statement that provides an algorithm for arriving at the value of a term where such algorithms may include sum, difference, product, quotient, Count, maximum, minimum, average. An example of a computation rule is: The total-amount-due for an order is computed as the sum of the lineitem amount (s) for the order plus tax.
Inference	A complete statement that tests conditions and upon finding them true, establishes the truth of a new fact. Examples of inferences are: If a customer has no outstanding invoices, then the customer is of preferred status. If a customer is of preferred status, then the customer's order qualifies for a 20 percent discount.

It should be emphasized that (the following ideas are very immature ):
Rules should not process business processes (any actual business operations), but the rules themselves. Including:
A. the domain object attribute is not updated in the rule;
B. do not access the persistence work of creating, updating, and deleting Dao objects;
C. Do not access any domain service methods that involve domain object update, network access, file operations, and email operations;
D. Only the provision of control information, status information, and other runtime data are generated, and the business process is used to complete the, B, and C restrictions.

The second question is: Do all the control logic need to be determined to be resolved using customizable business rules?
The answer is obvious, not all.
Parameters can be used to complete many control logic details. parameter configuration is also good for improving performance. Of course, parameterized configuration means that the business boundaries of the corresponding control logic are determined. Once the business logic is highly customized, a rule system is required.

The third question is: If so, what type of rule system do we need?
The classification of the rule system (my category is shown below ):
According to the function, rule systems can be divided into two categories: formula system and Orthodox rule system. I regard the formula system as a weakened rule system, which only performs formula calculation. This is also the most used function in Excel.
According to the language, the rule system can be divided into two types: programming language rule system and DSL rule system. The class DSL is closer to the natural language and the Problem Description Language.
Based on the engine, it can be divided into a script system and a reasoning system. For example, jrule supports two technologies at the same time: Checklist and forward chain. When checklist is used, it is a script system. BTW: jaskell of ajoo is a good script system.
What rule system is used depends on the needs of the system.
In more cases, the system does not need to do Reasoning (because people do it at the design time). A script system can meet the needs, and a weakened formula system is simpler and more practical.

The following is a related topic I opened on javaeye:
Rule system or script system, natural language, DSL or Java language

The fourth question is: Once the rule system is determined, who is the target audience of the system, that is, who uses the system?
Whether the audience is developers or customers is a problem.
If you are a developer, all you need to do is map the designed objects to the rule system without additional work. If you are a customer, you may have to do more work.
The problem is that system design usually adopts the OO principle, while oo pursues fine-grained design, which is not a problem for developers. But for the customer, what the customer sees or understands (if he can understand it) is a coarse-grained concept. So we have to do some extra work-encapsulate different objects (associated) into an object.

Once a class DSL is usedIn the rule system, what we care about is not a program, but a problem description.. Although the DSL-like rule system will eventually generate program code (using code generation technology), it is obvious that we are more concerned with use case (User story ). Both developers and customers can better understand system behavior.
 
Similarly, because code production technology --Generative programming(Pulled another height, Hoho), the overall benefit is obvious (this ...... Advertisement ). For more information, see the book Generative programming.