Order processing in 2500 BC
This page is published under the terms of the licence summarized in the footnote.
You might think the kernel entity type in an order processing system is “Order”.
This short paper argues that Order is the most artificial of the entity types.
By contrast, Customer, Product Type and Product Request are relatively natural and consistent entity types.
A common vehicle for teaching domain modelling is an order processing system.
People can readily understand the business process of placing Orders for Product Types.
And a small case study is easily enriched with business rules.
There may be precondition rules like Order quantity must be < Stock on hand.
And post condition rules like line item value = Order quantity * Product unit price.
And Order value = sum of line item values.
People often say that we build domain models to model “the real world”.
However their image of the real world is often a visual one, of screens, forms and reports.
They envisage the ordering process to be the action of completing an Order form on screen or paper.
They see the workflow as starting with the empty Order form, which is then populated with line items.
The Order is viewed as the root of an aggregate entity, and each line item as a detail of that entity.
However, consider the Sumerian business scenario below.
The Sumerians evolved from picture-writing into cuneiform, which means "wedge writing" in Latin.
Cuneiform was written with a wedge-shaped stylus (cf. ones used on today's hand-held computers).
Writing was inscribed into damp clay tablets, which were then baked until hard.
The Sumerians’ libraries of clay tablets contained their laws, business transactions, and literature.
Customer walks in.
Shop keeper: “Good morning, what can I do for you?”
Customer: “Good morning, I’d like two small clay tablets and two large ones please.”
Shop keeper: Holding these two requests in mind: “Anything else sir?”
Customer: “Hmm.. my stylus is a wearing out, I’d better get a new one.
Shop keeper: Holding three requests in mind, looks for the requested products and returns.
“Here are two small clay tablets and a stylus.”
“I’ve only got one large tablet in stock I’m afraid.”
Customer: “Will you be getting more large clay tablets in?”
Shop keeper: “Oh yes.”
Customer: “And I don’t like that stylus. Have you any like my old one?”
Shop keeper: “Not now, but I can get one for you.”
Customer: “Good, I’ll come back for one large tablet and the stylus.
What price for what I have today?”
Shop keeper: “Two small tablets and one large one.
That’ll be two shekels, plus one shekel pyramid building tax.”
Customer: “Here’s the money.”
Shop keeper: “Thank you. What’s your name sir?”
He marks a clay tablet with the Customer’s name and two outstanding Product Requests (a “back order”).
Customer: “Goodbye and see you soon.”
The Customer’s primary concern is three discrete Product Requests he articulated.
Second to that is which "Order" they are attached to.
<![if !supportLists]>· <![endif]>One Product Request was met in full today.
<![if !supportLists]>· <![endif]>One was divided into two parts, one for today and for a future "back Order".
<![if !supportLists]>· <![endif]>One was spontaneously added today, then swapped to the same future Order.
The Customer identifies his Product Requests by Product Types, and remembers the shop address.
The shop keeper has many Customers, so identifies the requests by their Product Types and the Customer name.
Given the volume of business in a shop is limited, there is no need for a line item number.
The individual Product Requests are of primary importance in the minds of both actors.
The Customer and the shop keeper held those Product Requests in their memory during the ordering process.
The Product Requests made today evolved through discussion and research into the stocks on hand.
<![if !supportLists]>· <![endif]>Two requests were paid for with no prior written record (though one may be made after).
<![if !supportLists]>· <![endif]>Two were recorded on a clay tablet, to be delivered and paid for later.
However, the Customer may never turn up to take delivery of those products
Or else, may turn up and further add, change or remove requests on that “back order”.
An Order is a batching of Product Requests for delivery or accounting purposes.
It is a device that saves transporting and paying for each Product Request separately.
It is potentially malleable, in that requests might be added, changed or removed, or swapped to another Order.
The rules for how it is created, modified and completed are flexible.
The concept of Order is the most artificial entity type in an order processing system.
By contrast, the Customer, Product Type and Product Request are relatively natural and consistent entity types.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 03/06/2015 20:09
Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website before the start and include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.
For more information about the licence, see http://creativecommons.org