Ayende posted an interesting question recently about writing a DSL for business rules. His position that the context in which a rule runs should be a first-class construct in the DSL is a very important one and I think would help make the development of rules almost doable by non-programmers. Maybe. ;-)

In reading the comments, there were requests for tooling and visualization, and concerns that just running the rules in order wouldn't do the trick. While reading, I kept getting this nagging feeling I'd seen this before. Then I realized - he's building a production system.

Production systems have been around for decades in the AI community, and are also very useful in language parsing theory. I most recently saw them back during grad school as part of building UI widgets of all things. It turns out that version of a production system (from this very good, readable book) looks like it maps quite well to the business rule processing too. (although when did the price go to $90? That's insane!)

Anyway, the idea of a production system includes fields, conditions, and productions.

The system has a state. This state is a combination of fields, where each field is an independent state variable. The conditions are the possible variables that a field can have. Looking at Ayende's example, there's not a whole lot of direct state, but fields aren't just state variables. There's also input events, actions, and queries. The input event field looks like this:

Inputs { *OrderShipped, *NewOrder, *BouncedCheck, *RefusedCredit }

(The leading * is a convention saying this is an event).

Next up, queries - this lets you express boolean true/false tests. There's two queries here:

CustomerQueries { ?CanSendSpam, ?IsPreferred }

(Queries have leading ? by convention)

And finally, actions, which are simply methods that are executed:

OrderActions { !SendMarketingStuff, !CallTheCops, !ApplyDiscount, !AuthorizeMoreCredit }

Finally, we have productions. A production is simply a pair of tuples of conditions. If the one on the left matches current conditions, the ones on the right are applied. The example in question comes down to:

*OrderShipped, ?CanSendSpam -> !SendMarketingStuff
*BouncedCheck, ?IsPreferred -> !AuthorizeMoreCredit
*RefusedCredit, ?IsPreferred -> !AuthorizeMoreCredit
*NewOrder, ?IsPreferred -> !ApplyDiscount(5.percent)
*BouncedCheck -> !CallTheCops
*RefusedCredit -> !CallTheCops

This looks a little more technical than the original DSL, so I wouldn't recommend you make your business analysts write this. But it buys quite a bit. You can simply scan down the list and see how the system runs. You can build a GUI tool that displays a simple grid - inputs on the left, actions on the right. You can sort by the inputs and queries and quickly find out everything the system could do in response to a particular input. And it's trivial to see if you have contradictory rules - you'll know because you'll have two productions with the same tuple on the left.

Anyway, I just wanted to drag out some stuff from my rusty education. I think a little rigor sometime can actually make things easier to use.