Diving into Domain-Specific Languages: A Practical Guide for Developers

Unlock the potential of DSLs to simplify complex tasks, improve communication, and create more efficient development workflows

I was able during these two last weekends to read Domain Specific Languages by Martin Fowler. This time investment was very much motivated by the following problem:

Many times, in e-commerce applications, some product data and meta-data will be setup by content engineers and will drive the product categories and customisation pages that will be used by the end users to select their final product configuration.

I began wondering if the introduction of a DSL with an associated Semantic Model (see description below) would allow to extract the product customisation code from the many other concerns of the codebase. Part I of this article will be a quick summary of Martin Fowler’s excellent book - Part II will be dedicated to how such a generic solution could be potentially architected.

According to Martin Fowler, a DSL is:

“a computer language of limited expressiveness focused on a particular domain”

We can talk about an internal vs external DSL:

• Internal DSL - a particular way of using a general purpose language. Rails, Ruby most famous framework is often seen as a collection of DSLs

• External DSL - a language separate from the main language of the application it works with. SQL, CSS, SASS (a DSL that compiles to another DSL!) and HTML for example

Another way to look at a DSL is a way of manipulating a library or framework - in this book’s context the library is the Semantic Model I mentioned above. Usually the hard work is building the model - the DSL is just layers on top of it

Again, Fowler describes a few reasons of why to use a DSL:

• Improving development productivity

• Communication with domain experts (content engineers, product managers, ..)

• Alternative computation model (vs imperative model of computation) more adapted to the domain focus

1. Decision tables

2. State machines

3. Production rule systems

4. Dependency networks

The book is long and I will not try to replicate everything here - I really encourage everyone involved in developing digital products to read the book - but my summary of the seven main steps to implement an external DSL are:

1. Implement a Semantic Model

2. Design the domain language

3. Define the EBNF grammar for the language

4. Use a parser generator - e.g. antlr - to generate a parser from the EBNF grammar

5. Leverage the flexibility of the parser generator to make the parser generate an AST (abstract syntax tree) that is easy to navigate and populate the Semantic Model

6. Use the generated parser to parse the DSL and generate the AST

7. Populate the Semantic Model from the customised AST

In Part 2 I’ll try to describe a possible approach for extracting the product navigation and customisation code from the rest of an e-commerce codebase by using a DSL to configure the data and meta-data that will drive the Semantic Model embedded within the application.