Domain Specific Language (or asking for directions in 10 different languages)

Imagine traveling to a foreign country and needing directions to your hotel. You are not fluent in the language of the country you are visiting, so you install an application on your mobile device to aid in translating your language into the country’s native language. Now you have a remedial way to take your native language and translate what you say into something that could be understood by the residents of the foreign country. This is an example of what domain specific languages are in the world of computing.

A Domain Specific Language (DSL) addresses a specific range of concerns. In the example above, I give a specific usage of a DSL – translating data from one format into another format to be processed in a specific way. As Martin Fowler states, “[a]n external DSL is a completely separate language that is parsed into data that the host language can understand” . So, the example given previously is a use case for an external DSL. We want to ask for directions in a given format, and receive directions in the same format. It’s a kind of pipe and filter approach to processing. Data enters a pipe, is filtered and manipulated, and then processed at the end of the pipeline. Data from the other end of the pipeline is just processed back to us in a format we natively understand.

An internal DSL is a “particular [way] of using a host language to give the host language the feel of a particular language” . An example is implementing a builder pattern within an application to create objects. The builder pattern gives a different “look and feel” to the host language. For example, object creation becomes more intuitive. Consider the following Java code snippets:

Instead of using a series of mutators (setters) to set required values, or using a complicated constructor, we use a series of descriptive mutators chained together to create the object. The internals of building a Person are not visible in the second example. In other words, you do not have to instantiate an Address in order to build a Person – the builder pattern takes care of building the Person with the Address association.

One application of a DSL is creating a language that business end users can use with little training, and is typically the goal of a business rules engine (should be citation to Gartner) . Most business end users I have met are not programmers or developers. Some are considered “power users” or subject matter experts (SME). A SME can communicate in a specific way, which is communicating tacit knowledge about the business, but in non-technical terms. Some SMEs can write SQL, but have little understanding of what’s required to build the software architecture needed to populate data sources. As a result, there is a disconnect between business knowledge and technical knowledge. Providing a DSL to business end users reduces the disconnect by giving business end users a way to communicate business rules in business language, but performing technical operations.

Consider the following example of a DSL:

So, when a policy has auto coverage, the policy’s auto premium is greater than $100.00, and the insured has less than 2 auto claims filed, reduce the policy’s auto premium by 5% (or, make it 95% of what it is today). The code written is (hopefully) simpler for a business end user to create and read. Using a DSL to process the code takes what is provided and perform such actions as querying a database of policies and claims, and perform comparisons as outlined in the code created by the business.

One of the ways of creating a DSL is to create a grammar, and then using the grammar to create a parser that breaks down the grammar and actually performs actions based upon the grammar provided. In the previous example, we need to break down the sentences into actions to be performed to evaluate the data (policies and claims), and then manipulate the data according to specific expressions (rules) provided. ANTLR, created by Terrance Parr, is an API that provides a way of creating grammars and then performing actions based upon the evaluation of sentences and expressions provided.

Creating a grammar is not an easy as it looks. Consider the example of asking for directions. Each language has a specific syntax, or way of constructing sentences, based upon grammatical rules. Most romantic languages have different placements for nouns and verbs than English. Japanese, which is a language I have no understanding of, uses a difference character set than English. Just taking the written form of English and translating the form into Japanese is a daunting task. The same ideas apply to creating a business language that is both flexible and easy to understand takes time.

Drools, a business rules engine implementation by Jboss, uses a DSL in order to create and evaluate business rules. Rules are written in a rules language, and then evaluated by the engine.

As I begin my question to create a business DSL, I find that it is a lot of work to transform the written word into something usable within an application. It is not as easy as it may appear to be at first glance. Much of the problem is find a concise way to communicate business rules into application code. But, I believe it is a journey worth taking.