Speaking broadly, most applications of rules (and rules themselves) fall into one of the two categories:

• Constraint solving or calculation applications

• Business rule applications

In the former, the problems are generally complex algorithmically speaking - in other words, they are a class of problems that are quite hard to solve with "traditional" means, but quite easy with rules. The Golf example (in the examples download) is one of these types. It is basically just a single rule, which is not particularly complex, which plucks out a solution to the problem from the solution space. Doing this without rules would most likely not be as easy, and almost definately not be as expressive. In this class of problem, the rules can basically be read as the constraints of the problem, letting the rule engine find the solution.

In the latter case, typically there would be large numbers of simple rules, which represent a statement of truth about a business. They are not complex algorithmically, but can be numerous, and change frequently. A common case for this latter type is when you need rules for "special" cases, for instance pricing rules for specific customers (or classes of customers).

It is worthwhile thinking through which archetype your system falls into (may be a mixture of both). This may effect your methodology in capturing the rules, the rule language used, and even your domain model. For "solving" type rules, you will have a fewer number of more complex rules, and the rules should map to a description of the problem ideally - these rules will most likely be technical, but should be understandable to someone with a deep knowledge of the problem. Use plain DRL for these rules.

For business rules, consider decision tables or DSLs, the rules will most likely be simple and numerous, with many re-used components. You domain model should be as flat as possible. The business rules should be clear and readable to someone familiar with the domain (they may not personally know all the rules off by heart of course, but they should be able to pick out a rule, or group of rules, and describe what they say about the business).

In any real world system, it is likely you will have a mixture of the archetypes - if this is the case, consider splitting the rule base along those lines where different people maintain the "technical" or "solving/calculation" rules to the business rules.