I have taken in my hands this book once again, driven by the fact that since 1st of July I have joined a new team and a new project. After years of experience in software development area I have, no doubt, my own point of view on enterprise architecture. But in this post series I will try to comment and polemist with myself and the Author (well-know Author) on different themes he has touched in his book. The fist one is “business logic”.

In the book I have found these sentences:

“Then there’s the matter of what comes under the term ‘business logic’”. I find this a curious term because there are few things that are less logical than business logic.”

“A few thousand of these one-off special cases is what leads to the complex business ‘illogic’ that makes business software so difficult.”

Curious, in my opinion those “thousand of these one-off special cases” define very exactingly the business logic. Business logic without those special cases would be just “logic”, that we can find everywhere in our environment starting with remote control. But the main problem for most architect and developers is to understand that we are not tolerating any “acceptable uncertainty” like other areas do. Let’s take a simple example of a process of building a house. We are tolerating some uncertainty in a lot of cases, e.g. how windows are fitting into frames. It is ok, to have, just shooting, a one or two millimeters “uncertainty” between the window and the frame. It’s normal, and it’s even desired!

But the software development operates on “atom basis”; there is no place for exceptions or toleration. Everything has to be strictly specified, and the word “exception”, so normal in case of business logic, has for us, architects or developers a terrible meaning. We don’t tolerate exceptions and that’s our problem. And the main task for us is to familiarize ourselves with those exceptions, “special cases” or whatever and to shift from the idea of identifying it as “illogic” to usual “business logic”.

Cuxhaven, 18.07.2007