Nick Malik declares victory for Dependency Injection in the battle of Rules Engines vs. Dependency Injection. Well, not so fast, Nick.

Nick argues that rules like UI form validation rules, error handling rules, routing rules in a process are better handled in code using a Dependency Injection Pattern, and not using a rule engine. I strongly beg to differ.For starters, I don’t see why there needs to be a comparison are in the first place, actually.

Now, here are some examples of business policies to begin with..

1. Insurance Policy Pricing Rules
2. Loan Eligibility Rules
3. Commission Calculation Rules

One important point that Nick Malik fails to mention is that these are scenarios where the business will be interested in seeing, knowing and eventually controlling the business rules.Externalizing your Business Rules, and using a Rule Engine to abstract out your Business Decision Layer provides you this visibility.

One thing that tends to be constant in such scenarios is that the number of rules is fairly large, rules tends to change pretty often, and new rules get added to the system. Now, Imagine implementing these business rules in code. This is what you’ll end up with.

1. Sophisticated Abstractions to model these rules consistently across the system.
2. Explosion of classes and abstractions.
3. An explosion of stored procedures that implement business rules at the database level

Even assuming that these business rules are implemented very carefully, show me one business analyst or business manager who can even look at these business rule implementations and understand what these do.

Of course,you cannot use a rule engine and business rules externalization everywhere you see an if then loop in your code, or wherever you see a formula. Here are some guidelines to identify areas where you can use a rule engine.

1. The number of business rules is large
2. Externalize only those rules that you expect will change often
3. Externalize only those rules which the business is interested in.
4. Business Rules Visibility is important .
5. Remember this! Validation rules are typically written, maintained by IT. With Business Rules on the other hand, you should aim to involve your business analysts in writing, managing and evolving them eventually

See, there are scenarios, where you actually require a rule engine, simply because the abstractions and tools required to easily capture and implement these rules is just not easy with regular programming frameworks. Here are some examples.

1. Inference Rules (Rete or non Rete)
2. Decision Tables (Pricing Rules, Rate Tables)
3. A involved Decision making sequence, as represented by a Flow Rule (Sequential) (Loan Eligibility Decision Sequence)

There is no need to use a Rule Engine when

1. The number of business rules is small
2. The rules never change.
3. The rules are mostly simple parametric rules

Related Reading

1. Seven tips for your first business rules project.
2. The Kinds of Business Rules
3. 10 Steps towards the Agile Enterprise

Related Quote

The more things change, the more they remain… insane.
- Michael Fry and T. Lewis, Over the Hedge, 05-09-04