Why can't we write Business Rules in Java files instead of .drl files?

Question

I just got introduced to Business Rules, .drl files, Rule Engines and Drools.While exploring I realized that all those conditions and fact checking can be done in Java programs as well then why do we need to write .drl files and have a Rule Engine separately.

Examples I'hv found on internet does not distinguish between why we should a write a .drl file for a partucular Business Logic rather than putting the logic in a Java Class.
An explanation using an example would be a great help.

Answer 1

The commonly cited advantages of using a rule engine include:

• Declarative business rules: using a DSL which business analysts (rather than developers) can use to define business rules allows an approach like ‘let your developers do the coding while your business analysts manage the business rules’.
• Externalising the rules: this may (depending on the chosen rules engine) allow you to change those rules without rebuilding and redeploying your entire application.
• Non functionals: a dedicated rules engine may perform better (through concurrent execution, for example) than a series of if/then/else clauses buried in your code and similarly a dedicated rules engine may provide better diagnostics and visibility of rule decisions than a roll-your-own solution. Of course, these are not necessarily true however it is true to say that if a roll-your-own solution is to match or exceed a well used rules engine in this regard then it would take some non trivial development to do so.

(There are others but for the purpose of this answer I think the above suffice).

Of course, these advantages have more or less weight depending on the specifics of each case. So, for example, if the proposed business rules are very simple, are small in number, are unlikely to change and if there are relaxed expectations as to their execution time then many of the above advantages do not apply.

However, plenty of implementations started out small, simple and with an expectation of few changes in future only for all of those expectations to be challenged by reality :)

It's also worth nothing that to some extent you can use Drools and "put ... the logic in a Java Class" by using Drool's Java dialect.

If you are being encouraged to use Drools against your wishes then perhaps a compromise solution would be to wrap an interface around your rules implementation and start with a simple implementation of that interface allowing for the possibility of a Drools based implementation later if/when a compelling case can be made for it.

Answer 2

The idea is:

1. To not mix up business rules with application logic
2. To have .drl files separate from the application, so they can be updated separately.
3. Ideally, although I doubt this is ever realized in practice, the business subject matter experts could write the business rules themselves.