Rules Should be Based on Facts

What the documentation advocates is that you should not call one rule from another, instead, each rule should produce an outcome, and the outcome itself should trigger the next rule in chain. This way rules do not concern with what happens next, and instead they deal with facts (aha!). And if - instead of writing rules for facts - you focus on writing an ordinary flow of procedural logic, you do not really need the added complexity of a rules engine.
The difference is subtle, but not more subtle than rules like "don't put your business logic in view" or "don't put your database access code in your business logic".

 http://stackoverflow.com/a/7247643/2066936