Three-Level Order Pattern

(C) 1997 Lorrie Boyd, AMS Inc. Presented with kind permission.

Problem

Many business systems are driven by the concept of an order. The order needs to be simple to use while capturing complex and changing billing and costing requirements. During the analysis phase, how do you create a simple order structure which still allows maximum flexibility?

Context

The order can be thought of as a series of association objects. First, an order is an association which happens at a point in time between the business and the customer. Agreement rules are established. Then, products or services are requested at different times generating another association (between the order and the product) and a receivable. Finally, products or services are received or manufactured at different times, generating yet another association (between the order request and the product) and a cost.

The business needs systems to handle these complex changes over time. For example, within one order the business may need multiple different product requests at different points in time; or the business may fulfill the order with even different products at different points in time. Simple orders must be generated which request and fulfill one product all at once. However, even simple orders have the same separate behaviors for managing order rules, managing order receivables and managing order costs.

Forces

• Meeting some of the most high value and profitable business needs often requires flexibility in the order structure. The high value orders are often complex and require flexibility.
• The 80-20 rule usually applies. 80 percent of the customers have a very simple order and do not need complex support.
• Orders are viewed as a single piece of paper.
• Orders have different behaviors for different associations at different points in time.

Solution

Separate the order responsibilities into a 3-Level structure.

This solution provides the flexibility required for complex orders. It separates the order into three associated groups of responsibilities: rules, receivables, and costs. This 3-level structure allows these three elements to have independent behavior and to happen at different points in time. For example, one order could request many different products at many different projected times and prices. The same order could later be fulfilled by substitute products at different times for different actual costs. Since the top tier contains the order rules, it provides consistency across this flexible billing and costing structure. At the same time, if a simple order is for a single product, the top tier would generate the lower tiers on creation while maintaining the separate responsibilities.

The structure looks like this:

This structure can be described more specifically as follows:

Level	Description
First tier (Order)	An association between the business and the customer. Establishes rules for allowed products and services. Captures past orders as history. May want to project future orders for planning. Can generate one subordinate Order Request for simple single product orders.
Second tier (Order Request)	An association between Order and the requested product or service, following rules established in the Order. Establishes billing requirements for the product and contains all billing responsibilities. Allows multiple requests: for different products, different receivables, at different times, within one Order. Can generate one subordinate Order Fulfillment if there is no delay or difference between request and fulfillment.
Third tier (Order Fulfillment)	An association between Order Request and the product or service actually delivered. Establishes costs for each delivery and contains all costing responsibilities. Captures history of multiple cost items. Cost items may have many uses in the business that different uses may require different cost calculations. Allows multiple fulfillments: for different products, at different costs, at different times, within one Order Request.

Examples

There are many examples of orders in business systems, ranging from purchase orders for goods the business has available to sell, to work orders for services the business will perform if requested.

The purchase order example is nearly identical to the generic solution. Here, one PURCHASE_ORDER may have many ORDER_LINE_ITEMS, both historical and current, for different products at different times. Each ORDER_LINE_ITEM instance would be for one particular PRODUCT instance, with the Quantity_Ordered indicating how many of that PRODUCT have been requested. The ORDER_SHIPMENT captures when products are shipped, with the dates and quantities shipped (and even a different PRODUCT instance if a substitute PRODUCT is used) differing from the ORDER_LINE_ITEM. Thus, PURCHASE_ORDER is responsible for enforcing rules; ORDER_LINE_ITEM is responsible for calculating suggested price and total bill; and ORDER_SHIPMENT is responsible for calculating actual cost.

The purchase order example would look like this:

A more complex example is a service or work order. In this example, the WORK_ORDER is a request for services or work to be done. Employees fulfill the request by expending time and doing the work. There is no tangible Product object, but there is an multi-layered Order association with rules, receivables or billing, and costing responsibilities. An illustration would be:

In this example, a WORK_ORDER is for work to be done in one or many ROOMs. The ORDER_REQUEST is by ROOM, and provides the dates the work is requested, and the types of workers anticipated. If one WORK_ORDER is for work in multiple rooms, possibly at different times, then multiple bills may be needed. Separating the WORK_TASK_ORDER, through the Order Request pattern, allows work to be requested in different rooms and even billed at different times within one order. Once work starts, the time to complete the work (and the work itself) may differ from the original request. Separating the WORK_ASSIGNMENT, through the Order Fulfillment pattern, allows actual time to be captured and costs to be calculated separately from the requested service.

The three objects can be described as follows:

Class	Description	Responsibilities
Work Order	Agreement with the customer that work will be done.	Determines allowed pricing policy. Generates a default Task for simple work orders.
Work Order Task	An association defining work to be done in different rooms at a point in time. Complex orders will have different tasks in different rooms at different times.	Calculate bill. Schedule work in different rooms. Estimate work.
Work Assignment	An association defining planned or completed work by an employee on a specific Work Order Task. Used to cost employee's time.	Calculate labor cost per work order Calculate payroll costs per employee. Generate actual assignments from planned assignments.

Known uses

Examples of 2-Level Order (Order and Order Line Item) are common throughout the industry. For example, Martin Fowler uses the 2-Level Order and Order Line Item example in his discussion on object destruction. Such a 2-Level structure would apply to the simple case where orders are placed but never fulfilled. When the business fulfills Orders, there are additional responsibilities of tracking actual costs which require the third level of this structure. The author has used the 3-tier order structure in manufacturing ordering systems, telecommunications ordering systems, work order systems, and purchasing systems.

[ Previous | Up ]