Business rules are something every application programmers need to grapple with. Compared to the rules of technology, business rules are complicated, vague at times and mutating in nature.

While defining the employee table, you have defined that data type to the column "age" as NUMBER. That is a wise decision! Because it prevents the stupid HR clerks from entering values like "young", "oldish", "middle-aged" etc.

But for the business analyst, he has to add the following business rules for that column "age" for the system to function with a certain degree of sanity.

  1. Age should not be less than 18
  2. Age should not be over 60
  3. If the value of "position" is "Trainee" then age should be less than 25
  4. If the age is between 50 and 60, put the record on hold
  5. Age to be verified vis-à-vis last educational qualification and prior experience
The product that you are designing should have a module for capturing such user-defined rules in a segregated manner. We should keep purchase rules separate from finance rules;

Now the question is, how do you implement each of those rules in your program. It is a problem of converting a real-world thing into an abstract world entity. So we need to see how in our abstract world these rules fit in.

Your problem boils down to that of object state change at the very fundamental level. You represent the real-world entities in terms of objects, its attributes and values in your program. It is subjected to "events" which try to change its present state.

In theory, an object can have almost infinite states, even after satisfying database constraints. Take the case of the column "age" for example. It can vary from 0 to a very large number. The events shown are random and might produce a lot of mindless states.

The job of the "Rule Engine", shown in the above diagram, is to prevent all the absurd object states from materializing.

Where will you plug in these rules? Trust me, there will be many running into hundreds.

The answer is simple. Since we are talking about object state transition, the corresponding class should have the code for checking proper object state transition as per business rules. This is the very reason OOP was invented in the first place. You do not leave your data unprotected. You encapsulate it within layers and layers of rules.

Unfortunately, business software makers of COBOL generation and SQL generation studiously ignored that simple solution and ended up producing millions of lines of hard-to-maintain spaghetti code. While, game makers riding on OOP continued to make more and more complex games.

Millions of rules govern a character of a computer game at any point in time. They dwarf business objects like sales order, purchase order or customer in comparison. But the former get developed faster and sell cheaper!