REA-Hruby – Policy Pattern

A policy is a rule of practice or procedure to guide decisions and actions.

Business reality: Not everything is allowed – there are laws, systems, traditions, cultures, and internal company rules that constrain the economic exchanges or conversions that are possible or desirable in a given situation.

Core REA model: The core REA application model specifies the economic resourcesevents, and agents in a given business. The model allows users to plan and register any kind of economic event that is part of the application model; however, the model does not provide for rules that govern what economic events are allowed or not allowed in a given situation.

Problem: How do we make the business application aware that some economic events are not allowable or desirable in certain circumstances, and even prevent users from doing something that is prohibited?

Considerations:

  • The users of a business application should be able to create and modify policies that apply to economic resources, events, and agents.
  • It should be easy to find any policy in the business application. It should be easy to determine what policies apply to a specific group of agents.
  • If a policy changes, the application should be able to retain the old version of the policy, and also to execute the business logic according to the old policy.

Solution: The policy entity encapsulates rules or constraints on economic exchanges and conversions in the business application.

Example

Figure 1 illustrates an example of the REA application model with a Sale Policy. The Sale Policy can apply to Item Group, Event Group, and Customer Group.

Policy in the REA application model

Figure 1. Sale Policy in the REA application model.

The Sale Policy can specify that, for all Events related to specific Items and to specific Customers, certain rules apply.

Consider the policy specifying that an enterprise is not allowed to supply tobacco products to minors. The Supply Policy “Tobacco to Minors” is ap­plied to the groups “Tobacco Products,” “Supply,” and “Minors.” Figure 2 illustrates that if a user of the business system attempts to register an in­stance of the Sale economic event with “PM Box” as an Item and “Addy” as a Customer (illustrated by dashed lines), the policy would be enforced and the sale would not be allowed.

Sale Policy  in the REA application model

Figure 2. Sale Policy  in the REA application model.

What would really happen if the business application depends on the implementation of the policy. The system response could range from noti­fying the user of the business system about the violation of the policy (by raising an information event) to preventing him from registering the event.

Groups of moment in time

There are policies applicable only during certain time intervals. For ex­ample, the Sunday Rule Policy specifies that the Joe’s Pizzeria does not sell alcoholic beverages on Sundays. The REA application model in Figure 3 contains a group Period of Sale, representing a group of moments in time. The Period of Sale has the value “Sunday,” and Item Group, has the value “Alcoholic Beverages,” and they are related to the Sale Policy entity. If Joe’s Pizzeria attempts to sell an item that belongs to the group “Alcoholic Beverages” and the time of sale belongs to “Sunday,” the pol­icy would be enforced. Note that the Sunday Rule Policy is re­lated to the Customer Group, which means that it applies to all customers.

Sale Policy with time parameters in the REA application model

Figure 3. Sale Policy with time parameter in the REA application model.

Managing versions

If a policy is revised or even becomes obsolete, users of the business application need to be able to restrict its applicability in time, rather than deleting the policy altogether. As economic events are always registered af­ter they have occurred, users need to be able to register events against the the policies that applied when the event occurred.

The functionality of a policy can be implemented in a behavioral pattern like a Matrix Rule – a representa­tion of a policy where the columns represent groups or types of entities and the rows represent applicable policies.

Semantic Considerations

Policies should relate to entities at the policy level, i.e. to groups or types of entities, rather than to  individual entities at the operational level. Such policies have more explanatory power and allow for reasoning about the policy.

A policy entity does not have to be related to groups of commitments, as information about whether the commitments conform to the policy can be derived from the policies applied to groups of events.

Software Considerations

Users of a REA business application need to identify the right groups; other­wise, they cannot specify the policies.

It should be easy to determine which policies apply to a specific entity by identi­fying the group(s) of which this entity is member, and traversing the rela­tionships between groups and policies.

The information necessary to evalu­ate the applicability of a policy must be in the system. For example, if there is a policy not to supply alcoholic beverages to people under a certain age, the age of the buyer must be in the system.

We need to consider the intended results of individual policies, and to establish the infrastructure that supports these results. The results of policies always prohibit some events, but they can be implemented with varying levels of enforcement, from notifying the user of the application to preventing him from executing the prohibited action.

The Policy Pattern should express rules and constraints in the form of relations (instead of code) – then users can add, modify and remove rules without modifying code.

Source: Hruby, P – Model-driven design using business patterns – 2006

Previous: REA-Hruby – Structural Patterns at the Policy Level
Next: REA-Hruby – Commitment Pattern