The business rule approach views an organization from three distinct perspectives:
Companies are looking for ways to refine and test their business rules on a more timely basis. Our information systems need to be architected so that they are amenable to change, allowing an organization to rapidly prototype, implement and refine its business rules in response to market fluctuations. To meet the challenge of these competitive environment, information systems must be able to respond to events in a manner that is appropriate to the business objects involved and the business rules in effect at that specific point in time. These information systems must be designed to control behavior, not just processes.
Behavior is controlled by three constructs: the type of Event that has occurred, the state of the Business Objects on which the event operates and the organization’s business rules (Figure 1). A business object state specification, which is itself a business rule, identifies a set of property values that the business object(s) must assume to be considered to be in that state (e.g. Overdraft is a state of a checking account that occurs when its balance falls below zero). Many business rules are specified in terms of the business object states of interest to the organization (e.g. If an account overdrafts and the account is owned by a preferred customer, pay the checks. Otherwise, bounce the checks). Business rules are specified independent of the events they constrain, so that they can be used by any event that causes the related business objects to achieve a state which may invoke the business rule, even those events that we have not been able to anticipate.
When an event occurs, it follows its prescribed procedure plan, selecting the related business objects when required. At the point of selection, the business objects are in their "initial" state. The event may causes changes to that state as it continues performing its operations. If a business object...