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
See also
UltraStructure