The practical perspective of a state transition system

A user adds some products to the shopping cart, proceeds to checkout page, and clicks the Confirm button to make the order Confirmed. The user is re-directed to the payment providers page, where he or she enters payment details, and when the payment process finishes, the order is Paid, the total amount is collected from the user, who now has become a "customer".

 

If you look at the above scenario, you will quickly see that the order Processing doesn't really end there. There is more to it.

The involvment of the customer is over as far as the public e-commerce site is concerned. But the seller has to look at the order, pack the items bought and get a delivery service to get the items Delivered to the customer. After delivery the seller should get some kind of confirmation (in a normal scenario) and only then the order can be Closed. If the delivery could not be made, then it should be Failed, and the order needs to be Cancelled, and the payment Returned to the user.

 

Just return back to the above two paragraphs and note the following words in bold and italic: "Confirmed", "Paid", "Processing", "Delivered", "Closed", "Failed", "Cancelled", "Returned". What do these words describe? They describe the state that the order is in, at a given time. Also note that they are in a particular sequence, one state comes after the other.

 

Also note that, based on your implementation project, the states recognised in the order processing will differ. Some implementations would allow a state called Partially Delivered for example. 

 

It sounds quite simple and straight forward, but we will need a more precise and formal way of handling the above situation when we try to automate it in a computer application. That is exactly what the Litium state transition system does. It formalizes and represents states and their transitions in the order process.