When organizations evaluate business rule management systems, there are several way in which they can interpret the boundary of a rule system.
The business teams work at the “what do I want to do” level of abstraction and for them the requirement is quite simple. e.g. they want a system where they can define that a customer with life time value of more than Rs 5000 should not be charged cancellation fee if she cancels her order. Or a call from high priority client should be routed directly to the more highly skilled customer care agents who are free and can speak the customer’s preferred language.
The development team has a more ambiguous decision to make – what part of the statement mentioned above go inside the rule system and what should be kept outside. While the end result will be the same for the business team, the choice made will have important effect on how the rule system and the systems using this rule system evolve over time. It also decides what technologies are viable for implementation of both of these.
In the above example, we may decide that the system should encapsulate the entire semantics of the rule, i.e., it should encapsulate the meaning and computation of customer lifetime value. More specifically, the interface of a rule system should be something like getCancellationCharge(customer id). This is an excellent domain aware API which can be intuitively used from anywhere in the system. However, the implementation of this rule will also have to change if the order management system makes any changes to the customer LTV is tracked.
Rulette make a conscious choice to keep all domain context outside. This means that Rulette cannot calculate LTV For you and it does not understand what it means. Rulette’s interface looks like this – getOutput(String inputName, int threshold). If the input with name fieldName (“customer LTV” in this case) has a threshold more than 5000, output should be zero. The application which uses Rulette has to understand what customer LTV means as input and what zero means as output.
Should a rule management system have to change if the implementation of the system about which the rule is written changes? If it does, can the rules be considered to be fully decoupled from use of rules? This is a decision you have to make for your application and organisation.
Rule of thumb for using Rulette
If you can frame your rules in terms of IF something=fixed value AND something-else=other fixed value AND something-else-again between fixed value 1 and fixed value 2, THEN outcome, then Rulette is an excellent choice for you.
However, if you want to frame your rules as IF something = derive some value from some input AND something-else = derive another thing from more inputs, THEN outcome derived from combination of inputs, then Rulette has been deliberately designed to not serve your use case. You should consider using Apache Drools or something like that.
