Domain-specific programming languages even a business analyst can use

In plain English, domain-specific languages let users define business rules, help ensure applications do what they're supposed to


A DSL (domain-specific language) is a language designed for a business or industry domain such as health care, finance, or insurance. It defines processing in terms of the nouns and verbs of your business rather than in terms of a pure computer language.

In most cases, domain-specific languages look like stripped-down versions of English that incorporate business jargon. DSLs are especially powerful when used with a rules engine - and most rules engines support some kind of DSL system.

The following is an example of a DSL used with Drools, a popular Java-based rules engine:

Compare this to the equivalent Java syntax:

A key advantage to this type of DSL is that business analysts who speak the jargon of the business, but who are not necessarily programmers, can write business rules on their own. On the other hand, programmers who need to know a lot about the business (but who are not necessarily qualified to determine business rules) can focus on the overall system.

Laying the groundwork for DSLs

DSLs disrupt the conventional software development workflow: A subject matter expert (SME) describes a business concept to a developer, who may not fully understand it, but who then implements it in a language the SME can't read. With DSLs, the developer works with SMEs to define a language specification; the SME then describes the business rules in the new language.

When you compare the two methods of development, the DSL-oriented one looks pretty good. Plus, having your business rules described in a DSL decouples them from the code, so new team members don't have to search thousands of lines of code to find the rules.

Why aren't DSLs in wider use? One reason: To achieve successful results, you need competent business analysts. This may sound harsh, but I've met maybe five of those in my entire career. Most of the business analysts I've met have been PowerPoint artists who couldn't quite make it as marketing people.

More to the point, defining a DSL requires lot of up-front work and planning. It brings to mind a rarely heeded Spanish proverb that Marc Fleury once admonished me with: "Slow down, I'm in a hurry." Yes, DSLs can result in more maintainable, robust, and cleaner software, but only if you're willing to spend the time thinking them through.

Putting DSLs to work

Several options are available for those who want to create DSLs. Drools is my personal favourite. It's a rules engine, it supports DSLs, and it features Guvnor, which allows you to organise the rules into manageable packages. But beware -- Drools is hardly a lightweight tool; it isn't even a single tool. It's a collection of tools that offers many features that have nothing to do with either rules engines or DSLs.

But there are many other approaches. For Microsoft's .Net platform, Irony offers a means of creating DSLs using a specialized expression grammar.

For Groovy fans, there's easyb. I like the lightweight simplicity, although it lacks the performance optimizations and tooling of Drools. It also leaves you with a bunch of Javaisms, like brackets ({}). I prefer using a language a bit more structured than plain English but that looks like plain English to the greatest degree possible. There are other resources and even an entire book on how to create DSLs for Groovy.

Ruby has a number of plug-ins, including Machinist and Cucumber, plus several great tutorials on the Web. The process of using a dynamic language like Ruby to create a DSL is somewhat different than using a rules engine like Drools or a pseudo-compiler kit like Irony. Ultimately, it's just as powerful.

Typically, SMEs are far removed from business logic. DSLs close that gap by allowing your business logic to be expressed in the language of the business by SMEs themselves. Yes, the scarcity of skilled business analysts is a problem, but if you're lucky enough to snag a few of them and you invest enough time and effort into developing DSLs, you may discover that using a domain-specific language to express your business logic makes a whole lot more sense than encoding it in a general-purpose language.

"Recommended For You"

Salesforce's steps up its global focus Banish IT jargon and acronyms says Saatchi chief