Tuesday, January 4, 2011

Theorems Regarding Business Logic

In yesterday's Rigorous Definition of Business Logic, we saw that business logic can be defined in four orders:

  • First Order Business Logic is entities and attributes that users (or other agents) can save, and the security rules that govern read/write access to the entitites and attributes.
  • Second Order Business Logic is entities and attributes derived by rules and formulas, such as calculated values and history tables.
  • Third Order Business Logic are non-algorithmic compound operations (no structure or looping is required in expressing the solution), such as a month-end batch billing or, for the old-timers out there, a year-end general ledger roll-up.
  • Fourth Order Business Logic are algorithmic compound operations. These occur when the action of one step affects the input to future steps. One example is ERP Allocation.

A Case Study

The best way to see if these have any value is to cook up some theorems and examine them with an example. We will take a vastly simplified time billing system, in which employees enter time which is billed once/month to customers. We'll work out some details a little below.

Theorem 1: 1st and 2nd Order, Analysis

The first theorem we can derive from these definitions is that we should look at First and Second Order Schemas together during analysis. This is because:

  • First Order Business Logic is about entities and atrributes
  • Second Order Business Logic is about entities and attributes
  • Second Order Business Logic is about values generated from First Order values and, possibly, other Second Order values
  • Therefore, Second Order values are always expressed ultimately in terms of First Order values
  • Therefore, they should be analyzed together

To give the devil his due, ORM does this easily, because it ignores so much database theory (paying a large price in performance for doing so) and considers an entire row, with its first order and second order values together, as being part of one class. This is likely the foundation for the claims of ORM users that they experience productivity gains when using ORM. Since I usually do nothing but bash ORM, I hope this statement will be taken as utterly sincere.

Going the other way, database theorists and evangelists who adhere to full normalization can hobble an analysis effort by refusing to consider 2nd order because those values denormalize the database, so sometimes the worst of my own crowd will prevent analysis by trying to keep these out of the conversation. So, assuming I have not pissed off my own friends, let's keep going.

So let's look at our case study of the time billing system. By theorem 1, our analysis of entities and attributes should include both 1st and 2nd order schema, something like this:

 invoiceid      2nd Order, a generated unique value
 date           2nd Order if always takes date of batch run
 customer       2nd Order, a consequence of this being an
                           aggregation of INVOICE_LINES
 total_amount   2nd Order, a sum from INVOICE_LINES
 invoiceid      2nd order, copied from INVOICES
 customer         +-  All three are 2nd order, a consequence
 employee         |   of this being an aggregration of
 activity         +-  employee time entries
 rate           2nd order, taken from ACTIVITIES table
                           (not depicted)
 hours          2nd order, summed from time entries
 amount         2nd order, rate * hours
 employeeid     2nd order, assuming system forces this
                    value to be the employee making
                    the entry
 date           1st order, entered by employee
 customer       1st order, entered by employee
 activity       1st order, entered by employee
 hours          1st order, entered by employee

Now, considering how much of that is 2nd order, which is almost all of it, the theorem is not only supported by the definition, but ought to line up squarely with our experience. Who would want to try to analyze this and claim that all the 2nd order stuff should not be there?

Theorem 2: 1st and 2nd Order, Implementation

The second theorem we can derive from these definitions is that First and Second Order Business logic require separate implementation techniques. This is because:

  • First Order Business Logic is about user-supplied values
  • Second Order Business Logic is about generated values
  • Therefore, unlike things cannot be implemented with like tools.

Going back to the time entry example, let's zoom in on the lowest table, the TIME_ENTRIES. The employee entering her time must supply customer, date, activity, and hours, while the system forces the value of employeeid. This means that customer and activity must be validated in their respective tables, and hours must be checked for something like <= 24. But for employeeid the system provides the value out of its context. So the two kinds of values are processed in very unlike ways. It seems reasonable that our code would be simpler if it did not try to force both kinds of values down the same validation pipe.

Theorem 3: 2nd and 3rd Order, Conservation of Action

This theorem states that the sum of Second and Third Order Business Logic is fixed:

  • Second Order Business Logic is about generating entities and attributes by rules or formulas
  • Third Order Business Logic is coded compound creation of entities and attributes
  • Given that a particular set of requirements resolves to a finite set of actions that generate entities and values, then
  • The sum of Second Order and Third Order Business Logic is fixed.

In plain English, this means that the more Business Logic you can implement through 2nd Order declarative rules and formulas, the fewer processing routines you have to code. Or, if you prefer, the more processes you code, the fewer declarative rules about entitities and attributes you will have.

This theorem may be hard to compare to experience for verification because most of us are so used to thinking in terms of the batch billing as a process that we cannot imagine it being implemented any other way: how exactly am I suppose to implement batch billing declaratively?.

Let's go back to the schema above, where we can realize upon examination that the entirety of the batch billing "process" has been detailed in a 2nd Order Schema, if we could somehow add these facts to our CREATE TABLE commands the way we add keys, types, and constraints, batch billing would occur without the batch part.

Consider this. Imagine that a user enters a a TIME_ENTRY. The system checks for a matching EMPLOYEE/CUSTOMER/ACTIVITY row in INVOICE_DETAIL, and when it finds the row it updates the totals. But if it does not find one then it creates one! Creation of the INVOICE_DETAIL record causes the system to check for the existence of an invoice for that customer, and when it does not find one it creates it and initializes the totals. Subsequent time entries not only update the INVOICE_DETAIL rows but the INVOICE rows as well. If this were happening, there would be no batch billing at the end of the month because the invoices would all be sitting there ready to go when the last time entry was made.

By the way, I coded something that does this in a pretty straight-forward way a few years ago, meaning you could skip the batch billing process and add a few details to a schema that would cause the database to behave exactly as described above. Although the the format for specifying these extra features was easy enough (so it seemed to me as the author), it seemed the conceptual shift of thinking that it required of people was far larger than I initially and naively imagined. Nevertheless, I toil forward, and that is the core idea behind my Triangulum project.

Observation: There Will Be Code

This is not so much a theorem as an observation. This observation is that if your application requires Fourth Order Business Logic then somebody is going to code something somewhere.

An anonymous reader pointed out in the comments to Part 2 that Oracle's MODEL clause may work in some cases. I would assume so, but I would also assume that reality can create complicated Fourth Order cases faster than SQL can evolve. Maybe.

But anyway, the real observation here is is that no modern language, either app level or SQL flavor, can express an algorithm declaratively. In other words, no combination of keys, constraints, calculations and derivations, and no known combination of advanced SQL functions and clauses will express an ERP Allocation routine or a Magazine Regulation routine. So you have to code it. This may not always be true, but I think it is true now.

This is in contrast to the example given in the previous section about the fixed total of 2nd and 3rd Order Logic. Unlike that example, you cannot provide enough 2nd order wizardry to eliminate fourth order. (well ok maybe you can, but I haven't figured it out yet myself and have never heard that anybody else is even trying. The trick would be to have a table that you truncate and insert a single row into, a trigger would fire that would know how to generate the next INSERT, generating a cascade. Of course, since this happens in a transaction, if you end up generating 100,000 inserts this might be a bad idea ha ha.)

Theorem 5: Second Order Tools Reduce Code

This theorem rests on the acceptance of an observation, that using meta-data repositories, or data dictionaries, is easier than coding. If that does not hold true, then this theorem does not hold true. But if that observation (my own observation, admittedly) does hold true, then:

  • By Theorem 3, the sum of 2nd and 3rd order logic is fixed
  • By observation, using meta-data that manages schema requires less time than coding,
  • By Theorem 1, 2nd order is analyzed and specified as schema
  • Then it is desirable to specify as much business logic as possible as 2nd order schema, reducing and possibly eliminating manual coding of Third Order programs.

Again we go back to the batch billing example. Is it possible to convert it all to 2nd Order as described above. Well yes it is, because I've done it. The trick is an extremely counter-intuitive modification to a foreign key that causes a failure to actually generate the parent row that would let the key succeed. To find out more about this, check out Triangulum (not ready for prime time as of this writing).


The major conclusion in all of this is that anlaysis and design should begin with First and Second Order Business Logic, which means working out schemas, both the user-supplied values and the system-supplied values.

When that is done, what we often call "processes" are layered on top of this.

Tomorrow we will see part 4 of 4, examining the business logic layer, asking, is it possible to create a pure business logic layer that gathers all business logic unto itself?


Jonathan Bartlett said...

"This may not always be true, but I think it is true now."

It will always be true - this is a fundamental aspect of computer science. For a programming language to be Turing-complete (i.e. able to handle any calculating task), it has to allow for open-ended loops. Therefore, if your language is to allow for any calculating task, it must allow for open-ended loops. So, as long as there are new problems to solve, there will always be unparameterizable code.

Tegar Fajar said...

Prediksi Bola | Judi Online | Bursa Taruhan Casino | Taruhan Bola
Judi Bola Terpercaya | Bandar Bola Online | Agen Taruhan
Prediksi Bola | Judi Online | Agen Casino | Taruhan Bola
Casino Online | Agen Bola | Prediksi Dan Berita Sepakbola
Agen Bola Online | Bandar Bola | Agen Casino| Situs Judi
Agen Bola | Taruhan Online | Bandar Judi Terpercaya
Agen Bola | Taruhan Bola Online | Agen Casino Terpercaya
Taruhan Bola | Judi Online | Agen Casino Terpercaya
Agen Bola Online, Situs Judi Casino Online, Bandar Taruhan Bola
Agen Casino | Judi Online | Bursa Taruhan | Bandar Bola
Agen Judi Bola | Bandar Bola Online | Casino Online
Informasi Terupdate | Sumber Berita | Sumber Inspirasi
Berita Terbaru | Inovatif
Berita Bola | Prediksi Bola Jitu
Hanya Untuk Anda Pecinta Dunia Maya
Info Masa Depan | Ulas Bola Hari Ini
Info Terupdate | Berita Inovatif | Berita Pilihan
Prediksi Skor | Berita Bola | Jadwal Bola
Prediksi Bola | Pasaran Bola | Berita Bola Online
Informasi Terkini | Prediksi Dan Berita Sepakbola
Info Berita Terbaik | Bursa Taruhan
Berita Terhangat | Info Masa Depan
Berita Terupdate | Sumber Berita
Hasil Skor | Prediksi Bola Terpercaya
agen texas poker dan domino
bola pelangi agen bola sbobet
Judi Online
Taruhan Bola
Agen Casino
Bandar Bola
Agen bola, poker, judi on-line, Prediksi bola, togel

Tegar Fajar said...

Info Skor Hari Ini | Update Bola
Prediksi Online | Bursa Taruhan Bola
Berita Terkini | Informasi Akurat Berimbang
Jadwal Dunia Sepak Bola | Prediksi Skor
Dapatkan Info Berita Bola Terbaru
Informasi | Berita Terbaru Era Masa Kini
Harian Bola | Bursa Online dan Berita Bola
Info Terakurat dan Terpercaya
Opini Info Terkini
Info Terkini | Kumpulan Informasi
Info Online | Berita Bola | Prediksi Skor | Cerita Dewasa
Semua Tentang Bola dan Khusus Dewasa
Portal Berita Bola | Prediksi Skor
Berita Informasi Terkini | Harian Bola | Ulas bola
Info Akurat | Prediksi Bola - Berita Bola - Jadwal Bola
Info Berita Bola | Prediksi Skor | Cerita Dewasa
Sumber Informasi Terkini | Cerita Dewasa
Berita Akurat Bola | Cerita Sex dan Foto Bugil | Prediksi Bola
Info Akurat | Cerpen Dewasa | Foto Seksi
Info Bola | Bursa Bandar Bola | Dewasa News
Prediksi Bola Malam | Berita Bola
Berita Baru dan Selalu Update
Informasi Terkini | Prediksi Dan Berita Sepakbola
Berita Terkini Dan Terpecaya
Bocoran Togelria.com | Prediksi Togel Singapura | Hongkong | Macau
Info Asia Skor | Prediksi Skor | Berita Bola
Info Berita | Prediksi Skor | Berita Bola | Tips Dan Trik
Ulas Bola Hari Ini | Prediksi Skor | Jadwal Bola
Agen Bola Sbobet
Agen Bola Sbobet - Judi Online | Bursa Taruhan Bola
Agen Bola Terpercaya | Judi Bola | Taruhan Bola Indonesia

Tegar Fajar said...

Buahpoker.com Agen Poker Domino Online Uang Asli Tanpa Robot
BUNDAPOKER.COM Agen Texas Poker dan Domino Online Indonesia Terpercaya
DaunPoker.Net Agen Poker Domino Online Indonesia Terbaik Terbesar dan Terpercaya
SaranaPoker.COM Agen Texas Poker Dan Domino Online Indonesia
GLOBALBOLA.COM Agen Bola Piala Dunia 2014 SBOBET IBCBET Casino Poker Tangkas Togel Online Terbaik Terbesar Dan Terpercaya
Buahpoker.com Agen Poker Domino Online Uang Asli Indonesia Terpercaya Tanpa Robot
Buahpoker.com Agen Poker Domino Online Uang Asli Indonesia Terpercaya Tanpa Robot
Daunpoker.net Agen Poker Domino Online Indonesia Terbaik Terbesar Dan Terpercaya

obat herbal ambeien akut said...

cara mengatasi berbagai macam penyakit secara alami
Obat Herbal Penurun Darah Tinggi Obat Herbal Ambeien Akut Obat Herbal Batu Empedu Tanpa Operasi Obat Herbal Sinusitis Kronis Obat Herbal Tumor Otak Jinak Obat Herbal Wasir Kronis Tanpa Operasi Obat Herbal Liver Kronis Paling Ampuh Obat Herbal Bronkitis Kronis Obat Herbal Usus Buntu Tanpa Operasi Obat Herbal Eksim Paling Ampuh Obat Herbal Gagal Ginjal Kronis

obat herbal glaukoma said...

pengobatan penyakit glaukoma secara alami tanpa operasi

Obat Herbal Glaukoma

obat herbal kanker hati tanpa operasi said...

cara alami mengatasi penyakit kanker hati tanpa operasi
Obat Herbal Kanker Hati Tanpa Operasi

obat herbal tbc said...

your post is very interesting
thank you for sharing
i really liked

Obat Herbal TBC

obat herbal polip hidung said...

excellant post

Obat Herbal Polip Hidung

Tom Dcruze said...

Hi..its a useful information.
A well-managed email database is by far the best way to boost sales without risking budget waste because it appeals to consumers who have already opted in to receive marketing information from you. Germany Mailing Lists

cara install yii2 said...

Great Post, I'm just create tutorial iinstall yii2 framework too, check this cara install yii2

kumar said...

I agree with the most of the points in this article and it’s great without any doubt. I think you made some good points in Features also. Really an amazing post! I would like to suggest your blog in my friend’s circle. Here I find everything in details. I hope I will see this type of post again in your blog.
Engineering Colleges, ECE Engineering Colleges in Chennai

Jamal Mohamed said...

I just keep visiting this blog from past two years. The posts here are unique and useful than other blog posts. Such a great info provided in this post. Keep providing useful post in this blog .I appreciate author for this valuable post.
Culinary Schools in Dubai | International Centre for Culinary Arts | Dubai Cooking Schools

ajay teja said...

Good work…unique site and interesting too… keep it up…looking forward for more updates.Good luck to all of you and thanks so much for your hard-work.
asi legal bangalore, asi legal,asi legal cochin,Shahul hameed