Why Business Rules Engine Matter

"A good DSL minimizes the 'communication gap' between a domain concept and the code that implements it" - Robert C. Martin

A Use Case

It looks like adopting a new technology is always driven by a business need.

The organizations, such as banks, have their own business processes (such as data gathering and document management). These processes are different from others but usually the differences are not big. How do we build a product which can be reused the similar features but still be adaptable with the specific requirements of each bank? Then, the answer is we should have a library/framework. There is an idea that we can implement this library/framework by using a business rules engine. Which has the following benefits:

• Be able to modify implementation of business domain at runtime (such as XML, CSV)
• Source code is more readable for both developers and domain experts. Therefore, source code can be consider it as a document

Since Business Rules Engines support for Domain-Specific Languages (DSLs)

"The purpose of Business Rules Engines is to define a representation of business logic in as human readable fashion as possible. This allows both subject matter experts and developers to work with and understand the same representation of the business logic." [3]

Then, why DSLs?

"A good DSL minimizes the "communication gap" between a domain concept and the code that implements it, just as agile practices optimize the communications within a team and with the project's stakeholders."
- Uncle Bob

"A well-chosen DSL can make it easier to understand a complicated block of code, thus improving the productivity of those working with it. It can also make it easier to communicate with domain experts, by providing a common text that acts as both executable software and a description that domain experts can read to understand how their ideas are represented in a system."
- Martin Flower

Should we use Business Rules Engines for manipulating the Graphical User Interface (GUI)?

The answer is: why not? This is a big idea and I've once mentioned about it at this post. However, I have experienced some issues:

• I have to make requests from client to server whenever I need a business decision. There are some cases unnecessarily to call the server such as client side validation (imagine you say a field is mandatory, for example). Sine we always consider the performance issues.
• The huge effort will be spent for complexity of building the stable framework for handling the communication between business rules and GUI. For instance, working with the component with a list of items such as table, list, so on.

How do you think? Leave your comments down below!

References:
[1]. Robert C.Martin, Clean Code, A Handbook of Agile Software Craftsmanship, Chapter 11 - System.
[2]. Martin Flower, Domain-Specific Languages
[3]. https://en.wikipedia.org/wiki/Domain-specific_language