Explicit Business Rules

Although the rules for processing transactions don't change every day, it seems like it sometimes! Rules that are embedded in programs are hard to change. Worse, many of the business rules are not implemented in a single place, but are spread among a set of programs. Any program that changes a file might have to know all the rules. Worst of all, it is common to need to how to process a transaction using last week's rules, or even last month's.

Making business rules explicit means you can store them in some kind of database instead of in the logic of a program. This has several advantages:

you can keep track of how they change over time, so
- You can process (or undo) a transaction based on rules in effect at the time that the transaction took place in the world, not at the time that the transaction was processed by the computer.
- If you make a mistake in the rules, you can back out the effected transactions, change the rules, and try again.
- You can add rules that take effect in the future, and will automatically get installed at the proper time.
each business rule is defined in one place, making it easier to change the system
you can change business rules without knowing a traditional programming language, so businessmen can customize their own systems.

On the other hand, it takes hard work to figure out what the business rules are and how you can represent them in a database. Any database system will be limited; if it weren't then it would be just like a conventional programming language.

Note that making your business rules explicit lets you stop programming in terms of the implementation language and start programming in the language of the rules. You are programming at a higher level, with all the advantages that entails, but you are still programming. Although the language is better suited to the problem, the people who use it are likely to be inexperienced programmers, and so might still have plenty of problems with it.

Therefore: store the business rules in a database. Each rule must have a time during which it is valid.

Every program that is table-driven follows this rule to a certain extent, but most of them still implement a lot of business rules in code. Moreover, few programs keep track of how the tables change over time.

This pattern is easier to follow (but still not easy) in a completely object-oriented language, since then you can make objects that represent the business rules.

Lots of people say this, but few systems that do it are documented. I saw a system for evaluating insurance policies that made the business rules explicit so that the business people could define them. Unfortunately, I can't talk about it. Another system that follows this pattern is Accounts[1], and it is only a research prototype that my students and I built. Accounts lets you define functions for computing account attributes using a simple language like that found in spreadsheets. I'm sure there are other systems, and I'd appreciate hearing about them.

--RalphJohnson