Paul King presented his take on how domain specific languages and scripting languages can and should be leveraged to express rules.
He places the expressiveness/ease of use of DSLs somewhere between generic languages and declarative data. The key goals DSLs try to achieve are:
- more expressiveness
- introduce a common metaphor of understanding between developers and SMEs
- enabling the SMEs to help design (or implement?) the business logic
- separate the technical code from the business logic code
- separate the lifecycle of business logic from that of the technical code
A lot of these are precisely what business rules are intended to cover. A lot of commonality there. Up to a certain extent, we could say that the languages introduced by the legacy BRMSs are DSLs of some sort.
The challenges remain the same as back in those early days:
- debugging at the code level – since DSLs get translated, sometimes through very complex mapping
- the creation and maintenance of the DSL is a (sometimes heavy) programming task
Paul presented a number of examples leveraging Groovy (which ‘I like), although the principles described could perfectly well be implemented in other DSL friendly scripting engines – those which really support meta-programming being the best choices (some I like are Boo and Nemerle ). You can find some of his previous work on DSLs on Github (https://github.com/paulk-asert/DSLsFromBeginnerToExpert).
Paul did a good job of describing the compromises and difficult choices that you face when defining a DSL. One key problem is the natural tendency to capture within the DSL parts of the business requirements for the rules themselves. Which basically violates the principle that you need to separate what is a specific requirement from the language support for its solution.
For me , in addition to this issue, the proliferation of DSLs and their evolution through time present significant challenges.
- The proliferation is a big problem: you may end up with multiple DSLs overlapping, and re-factoring to achieve commonality with what is then legacy code is really difficult. I do not know of good tools to help solve that problem.
- Evolution through time is also hard. In particular, non language specialists end up managing the task of maintaining and evolving languages, which is not really safe. Really, creating and maintaining languages is an arduous task, even more complicated than creating and maintaining APIs.
But that being said, the approach, well managed, presents a lot of advantages.
Towards the end of the presentation, Paul touched on something that is dear to me – leveraging a combination of imperative and functional expressions in combination with rules to solve problems. Functional programming tends to make declarative programming easier, but presents the challenge that it is significantly more difficult to use. Hiding that within DSLs through meta-programming capable scripting languages is a currently accepted relatively elegant solution.
Learn more about Decision management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager