Order
processing in 2500 BC
This page is published under the terms of the licence summarized in the footnote.
Abstract
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.
Contents
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.
·
One Product Request was met in full today.
·
One was divided into two parts, one for today and for a future
"back Order".
·
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.
·
Two requests were paid for with no prior written record (though one may
be made after).
·
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