2.2.2. When should you use a Rule Engine?
The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:
The problem is just too complex for traditional code.
The problem may not be complex, but you can't see a robust way of building it.
The problem is beyond any obvious algorithm based solution.
It is a complex problem to solve. There are no obvious traditional solutions or the problem isn't fully understood.
The logic changes often
The logic itself may be simple but the rules change quite often. In many organizations software releases are rare and rules can help provide the "agility" that is needed and expected in a reasonably safe way.
Domain experts and business analysts are readily available, but are nontechnical.
Domain experts are often a wealth of knowledge about business rules and processes. They typically are nontechnical, but can be very logical. Rules can allow them to express the logic in their own terms. Of course, they still have to think critically and be capable of logical thinking. Many people in nontechnical positions do not have training in formal logic, so be careful and work with them. By codifying business knowledge in rules, you will often expose holes in the way the business rules and processes are currently understood.
If rules are a new technology for your project teams, the overhead in getting going must be factored in. Its not a trivial technology, but this document tries to make it easier to understand.
Typically in a modern object-orientated application you would use a rule engine to contain key parts of your business logic, although what that means of course depends on your application. This is an inversion of the object-orientated concept of encapsulating all the logic inside your objects. This is not to say that you throw out object-orientated practices, on the contrary in any real world application, business logic is just one part of the application. If you ever notice lots of "if", "else", "switch", an over abundance of strategy patterns or other messy logic in your code that you keep having to change then think about using rules. If you are faced with tough problems of which there are no algorithms or patterns for, consider using rules.
Rules could be used embedded in your application or perhaps as a service. Rules usually work best as "stateful" component - hence they are often an integral part of an application. However, there have been successful cases of creating reusable rule services which are stateless.
In your organization it is important to think about the process you will use for updating rules in systems that are in production. You have many options, but different organizations have different requirements which are out of the control of the application vendors and project teams.