Enforcing Business Rules with Objects

This article by Jill Nicola 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.

From the author of

From the author of

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.

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.