Most business applications encapsulate business rules on many levels—from input validation to workflow steps—and most such rules are encapsulated in application code. That is, such rules are specified in a full-fledged programming language as part of an application's business logic.

Rules engines are designed to allow you to move such rules outside of mainline application code, and into a separate rules base. Rules in such rules engines are often specified in a mixture of a programming language and rule-specific markup that consists of conceptual if-then statements: If a condition is met, the then part is evaluated and executed by the rules engine.

In a recent IBM DeveloperWorks article, Implement Business Logic with the Drools Rules Engine, Ricardo Olivieri describes the open-source Drools rules engine. Drools is compliant with the Java Rules Engine API (JSR 94), and provides fast rules execution via the Rete algorithm.

A key point of the article is that externalizing rules to a rules engine is not appropriate for all types of applications: Java, or some other language, is perfectly fine for defining business rules in many cases. Only when rules become too complex will rules engines really help:

If your business logic code includes a bunch of if-else statements, you should consider using one. Maintaining complex Boolean logic can be a difficult task, and a rules engine can help you organize this logic. Changes are significantly less likely to introduce errors when you can express the logic using a declarative approach instead of an imperative programming language.

Another reason to use a rules engine is to reduce the cost of change:

Many organizations have strict rules about deploying compiled code in their hosting environments... If you need to modify the logic in a Java class, usually a long, tedious process must occur before the change makes it to the production environment... Even a simple change to one line of code can cost an organization thousands of dollars. If you need to follow such strict rules and find yourself making frequent changes to your business logic code, then it would make sense to consider a rules engine.

When do you think it is appropriate to externalize business rules, and when would you rather embed business rules directly in source code?