When Do DSLs Make Sense?

January 5, 2008 - 2 minute read -

Domain Specific Languages (DSLs) are discussed all the time. There is a lot of writing about implementing DSLs and many dynamic languages like Ruby and Groovy make it really fairly easy to do it. But rarely do I see it discussed how you figure out when it makes sense to implement a DSL.

Some people would say that DSLs are just another form of abstraction. Like a framework to help solve a specific technical problem, a DSL is a "framework" for solving a specific Domain problem. There is often a general discussion about the trade-off of cost vs. benefits of implementing a DSL. This cost/benefit discussion would be appropriate to a general-purpose framework as well. For the vast majority of applications, taken by themselves, the answer is it is never cost effective or appropriate to write a framework for one application.

The cost of creating a generalized solution could be appropriate when you have multiple (lets say at least three) applications that can utilize it. In addition to this rule is some sort of high volume of rules or highly-volatile changes. If you have different rules, behaviors or data that needs to happen on a per state and per product basis in an insurance company? If you need to be able to quickly change rules or variables based on financial market data? When one of these exceptions comes into play then there is a high benefit to the extra work of creating a DSL so the cost becomes one that is more acceptable. Additionally there are some dynamic languages, Ruby, Groovy, and Lisp variants for example that make implementing DSLs much easier to do. When you use those languages often the cost is reduced, because it's easier to implement, so that the benefit doesn't need to be as great for the payoff to work.

Rules for when to consider a DSL

  • You have more than two applications that could use the same DSL
  • Highly-Volatile changes are expected - multiple times a day perhaps
  • You have a very large number of cases that could grow exponentially as business or product lines grow
  • You are using a dynamic language that makes it easy to implement