The simplicity of business logic in models and implementation

For a long time this simple fact has been very obvious for me and my colleges when we have modeled business and implemented these as part of application development.

I think that the procedural paradigm has left a strong but false myth about complex business logic with a lots of code to implement it. I would like to open your eyes to see the truth. For some persons this might be embarrassing inconvenient in many ways because some people are billing lots of money based on this belief.

Lets start our tour from a small domain model that I will then somewhat extend and lets look what the deepest business processes really consists of.

This is of course a WepShop. This is extremely simple business domain ( and the model is still strongly abstracted) so this serves nicely as the first example.

All businesses live in time cycles. Then typically there are a few sets of this cycles according to their typical cycle length. Here we have two. The radius of the smaller and more active one is from a few minutes to typically less than hour. The radius of the second bigger circle is for weeks to years. Lets start from this. This is the process of acquiring book to the shop. When we talk of a real old style bookstore, the cycle was ( still is) from week to month sometimes years. The publishers send out catalogs and the shop owner chooses his selection and makes an order. Then the copies are printed and deliver. If the are not soled from the shop they must finally be dumped somewhere.

In a webshop the situation is of course somewhat changed. The physical copies don’t even necessarily have to be move to any “store facilities” but can the sent directly from the publisher to the customer. The other option is (like Amazon) that the webstore actually have some distribution center that serves as intermediate warehouse and the logistic center between producers and consumers. In this case the business process is to create the agreements and create the mechanism to choose the right products and deliver them to the distribution centers. So the only thing that shows up here in our abstracted business logic is the method newBook() in person. Even this class in a bit wrong place to put it, but in this case we have no better.

The other cycle ( the one the emphasis in the model is ) is on the selling side. In short the process is following: 1) the customer enter the shop 2) he/she asks for a set of books or stars to wander around to see if there is anything interesting. He/she pick up books. 3) He/she ends the visit at the cashier and makes the purchases.

In the model this is show in the nutshell as creation of two event-objects namely the walk and the purchase. So the process is totally contained in the following chain of method executions. 1) Person-object creates new walk and sets its parameters. 2) The walk send a message pickUp() to each interesting book. 3) Person-object sends endWalk() to the Walk-object when he/she in done. This method creates new Purchase-object and move the selected pick-ups to the Purchase-object, which finalize the process by collecting the payment.

All these methods are highly trivial. This ends the business behavior.

Now lets jump to me healthcare model ( see : https://jukkatamminen.wordpress.com/2010/03/24/genuine-object-model-health-care/)

Here the core business process is:

  • patient reserve a visit from a doctor.
  • the visit is started

  • the doctor create a patients status

  • based on this and the patients heath history the doctor creates a diagnoses

  • in some cases doctor needs some laboratory results to reach a diagnosis.

  • and start to treat the discovered disease.

  • finally doctor schedules an control visit.

This will show up as the following sequence of method calls:

It start at doctor-object with method newVisit(). This will create a visit and associate it doctor and patient. This visit then creates a new status with newStatus() and populates its attributes and bind its associations. Finally it will call this new object with diagnose() method to create a new event-object in the class on Disease. Next it will call disease-object with treate() method. This will create a new treatment-object and the circle is closed.

The conclusion is that all the business logic of all current businesses, when we talk about operation management and control is purely question of logistics. This is in most cases transformed in a sequence of creation of event-objects. So finally the businesses logic boils down very simple sequence of creation. This actually repeats over all typical business. When we look at the total business function this operation control and managements is only the simplest part of it. The in many cases there is what I would call “intelligent part”. In the question of healthcare this is all the accumulated knowledge of human physiology, chemistry and diseases and the deduction process to healing a sick person. An other example is insurance. The operation management cover the business from a insurance agreement through its life cycle events and this is very simple logically. This doesn’t include the complex risk analysis of the products and individual agreements.

These these real intelligence part are way out of the scope of von Neumann computing, but currently people are creating learning highly complex neural nets that potentially in future can accomplish these kind of tasks.