Using proper business terminologies in your spoken language in order to define your business rules makes business rules easier to understand. And it clears any ambiguity about what the business rules are doing. To do that you need to take advantage of Domain Specific Language (DSL).
Domain Specific Language (DSL) is a little language in a specific domain (i.e., your industry, your segment, your vertical, etc.) that allows you to build a model in your own language. Well, having said that, all of these models we introduced here can be considered as a DSL. Let's consider the set of business rules below for calculating the Potential Theft Rating of a car:
We have previously shown the use of Decision Table modeling in order to model this set of logic. Now let's see how we can model it in a Natural Language DSL using a set of when-then-otherwise-end blocks.
The first thing is to extract business terms from rules, so we can use them to write the business rules. By introducing the following terms, we can then model all of the above rules. This defines your business rule language.
- car is convertible
- car is listed in HTPA list
- Theft rating
For example, let's check R5,
As you can see, the definition of r5 is now pretty much the same as the actual business rule. Now let's define the logic for “car is not listed in HTPA” based on the defined business terms.
Don't worry, the editor will help you by proposing a list that you can choose from:
And finally, we have “Car is not listed in HTPA” as shown below:
As you can see, by defining the business terms, you can start modeling more and more logic that is based on business terms and other logic. When you are reading a business rule, if you are not sure about a defined business terms (i.e., “Car is listed in HTPA”), simply hover over it, and its definition will be displayed:
Also, the editor will provide hints on appropriate value types while entering rules:
With validation, DSL is able to identify the errors and issues with grammar on the rule and mark the line with an error icon:
And you know the exact line and position where that error occurred.
To fix it, simply go to that position, and let the editor propose suggestions:
As you can see in this picture, the connection operator between the two conditions was missing.
Test and Debug
As this is an executable model, when you are running your business rules they can be navigated, step-by-step:
And you can write unit tests using the business rules tester to assert expectations on both values and messages.
- If you want more details on how to build Natural Language in the advanced editor, you can check https://resource.flexrule.com/knowledge-base/natural-language.
- Would you like to learn the Natural Language API itself? Check https://resource.flexrule.com/knowledge-base/how-to-code-in-natural-language/
Last updated May 13th, 2020 at 12:51 pm, Published July 21st, 2015 at 12:51 pm
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.
[…] Sometimes you would like to model the business rules and logic in a textual format, still not use XML nor JSON because they are too noisy and their hierarchical structure are hard to understand. Then you can use Natural Language DSL which is a cleaner way to model business rules with no noise related to structure and it is full readable. The advanced editor also help you to write it easier. […]
[…] of course these information all come from the business glossary that you have defined your terms to shape your business […]