I'm currently part of a team developing a solution intended for small business. One of it's components is kind of a "dynamic business rules engine" (note the quotes) and because of it's nature we would like it to be highly configurable.

My idea was to implement/use an external DSL to write the rules with a simple configuration utility to create and edit them. We could also keep a set of "common" rules and distribute them with the application. An external DSL + the "editor" will allow us to fix or modify rules as needed, and our clients need that agility in their process.

My team members think that the best approach here is to provide the rules as plugins to the application and redeploy or upgrade those plugins, they argue that, in that way, we'll have better quality control given that testing the plugins will be easier than testing a DSL script. But in my opinion, maintaining a group of plugins, most of them in a "per client" basis will eventually become a living nightmare.

Bottomline my question is: Which solution do you think will work better with a small team of "jack of all trades" freelancers who have to develop/deploy/maintain/upgrade around four or five clients?

  • 2
    Have you thought about using an off-the-shelf rules engine? Commented Jan 11, 2017 at 20:50
  • 1
    I have, but since we can't make our mind around the DSL vs plugins stuff that takes us back to the same place: Does the engine provides an external DSL or do you have to hard code the rules in your app?
    – yorodm
    Commented Jan 11, 2017 at 20:59
  • 1
    With hand made DSL engine you add yourself another layer of software to maintain and develop over time. Yet deployment and such could be nightmare for plugins model. Maybe go with external rules source but just write them in some script-kind runtime executable form? Like Groovy in Java or something like this? That way you have flexibility and on-the-go ability to change those scripts and still retain power and testability of full programming language without hand made execution layer.
    – Vir
    Commented Jan 11, 2017 at 22:27
  • The power of plugins can be a drawback. Inappropriate, inefficient, or malicious behavior can be more easily prohibited in a DSL. Commented Jan 12, 2017 at 17:00

2 Answers 2


I am of the opinion you should not invest in a DSL with only 4 or 5 clients potentially using it. I am saying potentially because you do risk it being regarded as too complicated, ending up in the situation where your team will be the ones create these DSL scripts for your customers. Effectively creating a DSL for yourself.

What would -you- rather use? I like my regular programming language(s) and tools enough to frown upon having to learn yet another DSL.


Both will work. Both may not work

The success of the strategy is not about plugins x languages. The success of the strategy is in the information model of the interfaces you expose to the plugin/script language mechanism.

You can't expose the whole application subsystem directly. If you do, every change of the base app may break scripts. And the scripts will be able to access things that may corrupt the app.

I would advise to write a series of base interfaces and expose them to a script engine and to a plugin subsystem. The interface will be the same: Small adjustments and configurations can be done as scripts. Additional generic optional functions can be distributed as plugins.

It is a good idea to let your users make scripts themselves. Form time to time you inspect your user scripts, get the ideas, expand the concept and turn them in plugins that you can sell or increase the value of your app in the eyes of your customers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.