Most software written for companies contains rules relating to the problem domain the application is trying to solve. These rules are things like “All customers that spend more than £100 at one time will receive a 10% discount”, “Automatically delete any support requests written in capitals”, “Delivery Dates cannot be set in the past” or “Members who joined after such and such a date are not eligible for the pink elephant special offer”. These rules are called Business Rules.

Lately here at Loopo we have discovered the need for a more flexible and standardised way of handling our business rules in some of our applications.

As applications grow, the practice of having all business rules defined in code gets duller and duller as every time a rule changes, we need to provide a new build and also (idealy, at least) test all areas of the application in order to make sure that the changed code hasn’t affected anything else. Yes, we could put all rules in a separate dll and dynamically load it into the application but that would still require us to compile and distribute the dll for every rule change.

So wouldn’t it be much better to store all rules in an easy to read XML format so that even the customer can update the rules him or herself? Then you have some kind of software module that takes the XML file, converts it into code on application start, catches all relevant events generated from your application, finds the rules for this particular event and runs them, now that would be nice, no?

Well, there is such a thing, they’re called Rules Engines. This is not a revolutionary new concept, but suprisingly few businesses use them, this may be because their cost is either prohibitive (for commercially licensed software), their Open Source counterparts are too daunting to integrate into your application, or they simply cannot be shoehorned into your application by any chance. So I did what every good programmer does: I reinvented the wheel.

continued: Part 2