Design patterns and algorithms for applying rules to facts

Question

I am in the midst of trying to nail down requirements from a client for a pricing engine in a retail environment. We have defined the pricing engine as operating on a set of pricing rules that establishes new price points for purchased items based on existing items already in the shopping cart.

A simple price rule might be GET A SHIRT 40% OFF. A more complex rule might be GET A FREE SHIRT WHEN YOU BUY 2 PANTS AND SPEND AT LEAST $30.

The general industry practice for applying these rules seems to be final best price to the customer, but it has come up that there may need to be a ranking option as well as a stacking option.

Ranking will allow a rule that would otherwise lose out to win. Stacking would allow multiple rules to win.

I've reviewed many of the posts here on SO regarding rule engines and I need help determining if I should be looking at one of these tools as part of my design or if not what design patterns and algorithms might be applicable to the design.

It is clear that this is potentially an NP problem, and the number of items(facts) that I will be dealing with could exceed 100+ per transaction with repricing required every time a new item is added.

Answer 1

There is a nice article by Martin Fowler on Rules Engine and where to use them. See if helps

http://www.martinfowler.com/bliki/RulesEngine.html

Answer 2

A rule engine is very suitable. If the rule engine is reliable, fits into the rest of your architecture/application and is needed for a core feature of your application then go for it.

If the rule engine is only a small part of you application or even worse: is some code, which is not the same programming language than the rest of you application ... then you should reconsider. Every application part, which is external from your core applicaton (even the database is external to a java application) is a risk.

Then there are two possibilities: Program a simple rule engine by your own or make use of the Strategy or the State Pattern.