Enforcing Business Rules with Objects
- Toward a Business Rules Methodology
- A Patterns-Based Rules Methodology
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Imagine a world without business rules: subways and elevators taking off with open doors, perishable food being loaded into non-refrigerated trucks, automobiles with duplicate license plates, and people withdrawing money from your checking account. Not a very pretty picture, is it? In a world without business rules, business processes can be initiated by the wrong people, at the wrong times and places, and with the wrong things. Not only does system integrity go right out the window, but dangerous real-world side effects become very likely.
We rely on software to enforce many of these business rules, but translating rules about business processes into software routines is a non-trivial challenge. Object modeling techniques help by describing the business processes in representations that can be more easily mapped into software; however, rigorous techniques for enforcing business rules in object models are rare or nonexistent. This article introduces a methodology for enforcing business rules through object models that includes techniques for organizing business rules around objects, deciding when to check them, and distributing the work in objects.
Toward a Business Rules Methodology
The first step of developing a business rules methodology is to understand the relationship between a business process and an object-oriented system. An object-oriented system executes a business process by creating or accessing objects that represent the people, places, and things involved in the process and by recording events that occur during the process. These business objects are responsible for checking the business rules, so system developers must decide which objects check which rules and design appropriate procedures. The purpose of a business rules methodology is to eliminate the guesswork in mapping rules to objects and designing rule-checking procedures. Before explaining our rules methodology, a simple case study will help highlight the issues involved.
A Simple Case Study
Consider the simple business process of withdrawing money from an account. The object-oriented version of withdrawing money from an account involves objects for the account (thing), the customer (person), and the withdrawal (event). (See Figure 1.) Business rules regulate the process so that (1) a customer cannot withdraw money from an account he does not own; (2) a customer cannot make a withdrawal for an amount greater than the balance of the account.
){kind=link}
Figure 1 Object model of the account withdrawal business process.
Although the business rules are written in terms of the human actor, it would be a mistake to assume that the rules should be enforced in the corresponding person object. After all, in a complex system a person object may be involved in many business processes, so putting all the business rules in it would be unwieldy. Instead, business rules belong with the object they are restricting, which in this example is the account object.
How business rules are expressed in terms of objects also depends on when the rules are checked: during a final commit service or proactively whenever objects are modified. Checking during modification is safer because it keeps objects from entering invalid states, and allows immediate error handling and rollback on failure. Waiting until a commit to check rules allows the system to enter invalid states, and makes localizing and handling business rule violations more difficult because many objects are checked at once.
Proactive rule checking means that an account object can never establish a collaboration to a withdrawal object that does not satisfy the business rules. Using proactive rule-checking, the account business rules become as follows: (1) an account cannot collaborate with a withdrawal from a customer who is not also one of the customers owning the account; (2) an account cannot collaborate with a withdrawal whose amount exceeds the balance of the account.
This simple example yields three important lessons for building our rules methodology. First, business rules that govern how things are acted on by people in the real world become rules that the object representing the thing enforces. Second, although an object model describes which classes of objects collaborate during the business process, business rules constrain which objects in these classes can legitimately collaborate. Third, enforcing business rules when objects attempt to collaborate prevents invalid states in the account withdrawal system. Our next step is to use patterns to generalize these lessons.