Table Of ContentMEAP Edition
Manning Early Access Program
Domain-Specific Languages Made Easy
Version 4
Copyright 2020 Manning Publications
For more information on this and other Manning titles go to
manning.com
©Manning Publications Co. To comment go to liveBook
welcome
Thank you for purchasing the MEAP for Domain-Specific Languages Made Easy!
This book is written for developers interested in unlocking the potential of Domain-Specific
Languages (DSLs) to improve their daily software development life. To get through this book at
a good clip, you’ll need to have some skills in and experience with software development,
preferably using modern JavaScript. You’ll learn most if you go through the text with a
development environment at hand, trying out the code, and doing the exercises.
DSLs have been around for a very long time - in fact, one can argue that they even predate
the advent of computers.
Since then they seem to have gone through the Gartner hype cycle several times. It’s
therefore curious that learning about DSLs is usually confined to the more challenging parts of
university Computer Science curricula. I find that books available on the market either assume
too much prior Computer Science knowledge, are not practical enough, rely on a very specific
piece of technology, or any combination of those. This book is the result of the desire to try and
fix that situation.
It’s my goal to make the topic of DSLs -and slightly more general: that of software language
engineering- accessible to an audience that’s as broad as possible. Let me take you on a guided
tour through the essentials of the field. We start with the oh-so-important “What?” and “Why
(not)?” questions, and finish on a full-blown DSL environment or Domain IDE, with narrated
stopovers along the way at topics such as:
• Concrete versus abstract syntax
• Abstract Syntax Trees
• Crafting a user-friendly Web-based editor
• Code generation
• Business rules: definition and execution
As an encore, we’ll also address the “What else?”-question.
This book “cheats” by not crafting parser-based textual DSLs, but rather ones that use
projectional editing. Not only is parsing technology hard to master, but the resulting DSLs tend
to have a rather “techy” look and feel about them.
Projectional DSLs look and feel more like a modern business app, and are conceptually,
architecturally, and technogically much simpler. I’m afraid you’ll have to look elsewhere if you
really wanted to learn about grammars, scanners/lexers, etc…This books covers a lot of
common ground though: much of the content applies directly to the parsing-based world as well,
or has a conceptual equivalent.
Writing this book has been quite the learning experience, and I hope it will be equally
rewarding for you. Don’t be shy to post questions, and feedback in the liveBook's Discussion
Forum. Not only will you benefit from that, but also me, and by extension, your fellow readers.
— Meinte Boersma
©Manning Publications Co. To comment go to liveBook
brief contents
1 What is a Domain-Specific Language?
2 Representing DSL content as structured data
3 Working with ASTs in code
4 Projecting the AST
5 Editing values in the projection
6 Editing objects in the projection
7 Implementing persistence and transportation of ASTs
8 Generating code from the AST
9 Checking the AST
10 Implementing expressions
11 Generating code for business rules
12 Evolving a DSL
13 Designing a DSL
14 What we didn’t cover
Appendix. Setting up the development environment
©Manning Publications Co. To comment go to liveBook
1
1
What is a Domain-Specific Language?
This chapter covers
What is a Domain-Specific Language (DSL)
What does (adopting) a DSL(-based approach) do for an organization
When (not) to use a DSL
What are the key aspects of a DSL
If you’re reading this book, you’ve probably already heard about DSLs. You might even have
realized that you may need to use one. But do you really? And what is a DSL, and how would
you build one?
The tricky thing with teaching about DSLs is that it’s a very broad topic, with many
interconnections to other topics in both software development, and computer science. It’s also a
topic that can be -and is- looked at from many different angles. Don’t worry: this book will not
try to teach you everything about DSLs, or overwhelm you with unnecessary details. Instead, it’ll
take you on a carefully-planned route that walks you through a set of connected topics that cover
all the basics and skills that you need to craft your own DSLs. This learning path will be
example-driven, quite literally going from the concrete to the abstract. To that end, we’ll start
with sketching out an example business case for which we’ll build a complete DSL throughout
the book.
1.1 A business case: a car rental company
In this section, I’ll present a concrete, and representative business case in some detail. We’ll be
using this business case throughout the rest of the book as a running example, to keep things
concrete and grounded.
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
2
Imagine a local car rental company, which is in the business of renting vehicles out to
individuals. The company has a sizeable fleet of cars of different types, makes, and
configurations. Consider a prospective customer interested in renting a car from this company.
They would to input parameters like rental period, type of car, and contract type into the
company’s Web site, or an actual app on a mobile device, and ask it to produce a price quote.
Once they find a combination of parameters that produces a favorable outcome, they can
continue to make a reservation for a rental with those parameters. You’ve probably done this a
couple of times yourself.
Figure 1.1 A prospective customer uses a car rental company’s app to get a price quote
for a rental
Let’s have a closer look at how this piece of software (Web or native app) computes a price
quote from the input parameters: rental period, type of car, and contract type. A couple of aspects
that go into computing the price quote are:
Discounts may apply based on the length of the rental period, or by the presence of
holidays within the period.
Each type of car has its specific rates.
The contract type determines whether there’s a flat rate per day, or a rate based on
distance driven, or any combination of those, possibly with some mileage cap.
Discounts can also be given out for other reasons, like marketing campaigns.
Determining a price for the rental of a car based on the input parameters involves a lot of
business knowledge, or business logic. If we were to look at the code that computes the price
quote, it would probably be quite complicated, with a lot of nested conditional logic, in the form
of if-, or similar statements. We’d probably also see some intermediate state in the form of
variables that are initialized, set, or manipulated based on certain conditions. How did the
developers that wrote that code knew what they should be writing exactly? Let’s assume that the
developers weren’t themselves already experts on car rental, so they must have been handed
some kind of specification by the people in the company that set rules for these things.
But how would the experts from the business write that specification down? Typically, you
would expect a collection of documents that use natural language to describe the business logic.
As an example, the following sentences could be part of the specification of how to compute a
price quote:
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
3
Table 1.1mNatural language-sentences expressing business logic pertaining to
computing a price quote for an intended rental
If the rental period contains a national holiday, then a surcharge rate of 10% is applied to the rental price for that
holiday.
If the length of the rental period exceeds a whole week, then a discount rate of 5% is applied to the per-day rate.
If the car is a genuine gas guzzler, then an additional environmental fee of $10/day is applied.
Such business rules are of the form “If <condition>, then <consequence>.”. The condition part
specifies when this rule should trigger, or “fire”, and the consequence part specifies what should
happen in that case. Such business rules interact with each another to determine the various price
components, and subsequently the total price, from the input parameters. This is an often-used
format for specifying business knowledge, and logic, that’s useful for, and usable by business
experts. We’ll give a more precise definition of business rules later on, in chapter 10.
Computing a price quote for a prospective customer constitutes only a very small part of all the
work processes within the car rental company that require software. Other work processes could
be:
Confirming a reservation with the customer.
Having the customer change, or cancel their reservation.
Processing a customer coming in to pick up their rental.
Processing a car after it’s been dropped off by the customer.
Billing/invoicing.
Doing administrative chores for the cars in the fleet.
Translating a specification of all business logic involved with the work processes within an
organization that’s written by the business experts into working code is a lot of work. It’s not just
that there’s a lot of business logic: the specification itself must be checked for completeness,
consistency, and ambiguities. That requires plenty of back-and-forth between the software
developers and the rental experts. This way of implementing business logic is therefore usually
time-consuming, tedious, and expensive. As a side effect, the software developers will probably
be pretty good business experts in their own right, in the end.
The main reason that software development is like this, is that business experts normally don’t
have the background, knowledge, or skills to develop software themselves. Even though they
tend to be highly-educated, they typically have had no exposure to, or education in
programming. To put it another way: they are probably great at specifying the What, but
probably not at specifying the How. Wouldn’t it be great if they didn’t have to learn about all the
latest innovations in software development, but could “just” write down their business
knowledge using helpful tools?
In this book, we’re going to explore how to develop software tools for the business experts that
allow them to write down their business knowledge in a way that’s understandable for them.
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
4
Moreover, the business knowledge written down will be automatically be translated into working
software, without requiring a software developer for every change. This puts the business
experts, rather than the software developers, at the center of software development. We don’t just
do that to make the business experts feel more important: we’ll get back to all the advantages
(and some disadvantages) in section 1.3.
IMPORTANT We call the form in which experts can write down their business knowledge
a “Domain-Specific Language”, or DSL for short.
It’s a software language that’s specifically crafted for the domain that
the business experts “inhabit”, or “own”. It’s precisely defined, and its
language constructs carry certain, precise meanings. It has a clear notation
, or “syntax”: a system of writing that’s readily understood by the business
experts. It can (and often does) look like text, or even natural language, but
is not restricted to that.
A DSL comes with -or even: as- a set of software tools that allow the
users of the language to write it down, and to process it further. It’s not a
genuine programming language, nor is it a general modeling language, but
it shares a lot of characteristics with those types of languages.
In section 1.4 we’re going to have a deeper look at what a DSL is.
In the course of this book, we’re going to develop DSL tools for the business experts of the car
rental company so they can specify their business knowledge with it. By doing this, you will
build the skills to create original DSLs to meet your own needs. In the next section, we’re going
to explain more precisely what DSL tools we’re going to be creating.
1.2 Using a DSL-based approach for software development
We’re going to learn things that will allow us to break up software development in such a way
that business experts will be at the center of it. The centerpiece, and key enabler for this is a
DSL: the Domain-Specific Language. Instead of trying to write down their business knowledge
in documents using natural language, business experts are going to use a tool called a Domain
IDE to write down their business knowledge as content in the DSL: DSL content. Typically, an I
ntegrated Development Environment is used by software developers to write software in some
programming language(s), but our Domain IDE will target business experts. By designing the
DSL, and the Domain IDE in the right way, this DSL content will not only be understandable,
writable, and maintainable by business experts, but will also be precise enough to serve as a
specification. We’ll call this approach a DSL-based approach for software development.
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
5
NOTE To keep naming aligned with the term DSL, we’ll talk about domain experts
rather than business experts. This is OK since we can consider all
businesses to be domains in their own right. We’ll come back to this in
section 4.
Figure 1.2 Using a DSL-based approach to develop a Runtime using a Domain IDE
Instead of implementing the required software directly by translating a specification to code, the
software developers will primarily develop the Domain IDE that the domain experts will use.
They will also make sure that the Domain IDE builds working software, by generating code
directly, and automatically from the DSL content. The software developers also take care of
building any parts of the working software that can’t be specified by the domain experts. Here,
“working” means: “all the code compiles, and runs according to the specification”.
To avoid getting bogged down in whether a piece of software should be called an “app”, or an
“application”, or where it’s even really running, we’ll call the entire desired software system the
Runtime. In the case of the car rental company, the Runtime consists of both the app that
customers use to arrange a rental, and the point-of-sales-type systems that employees use to
execute work processes. Both the customers as well as the employees are called business
stakeholders. We don’t call them domain stakeholders since not all of them are really inhabitants
of the domain: customers, in particular, are just serviced by the domain.
The Domain IDE is an application in its own right, but not the software system that’s the end
goal. These days, it makes sense that the Domain IDE should be a Web app, running in the
browser. That not only avoids that domain experts have to install and update an application, but
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
6
Web apps are also easier to make work across multiple types of computing devices. Lastly,
developing Web apps really is a mainstream skill, so a lot of software developers already have
that skill.
1.2.1 The design of the Domain IDE
To get an idea of what a Domain IDE looks like, I’m going to cheat, and use my prescient crystal
ball to make some screenshots of the Domain IDE for the car rental company. We saw in Table
1.1 above that domain experts should be able to express the following kind of business
knowledge in the Domain IDE:
If the rental period contains a national holiday, then a surcharge rate of 10% is applied to
the rental price for that holiday.
If the length of the rental period exceeds a whole week, then a discount rate of 5% is
applied to the per-day rate.
If the car is a genuine gas guzzler, then an additional environmental fee of $10/day is
applied.
So, it should be possible to create, change, update, and maintain proper DSL speak truthfully
representing this business logic in the IDE. Let’s have a look in my crystal ball to see what a
similar set of rules could look like. To avoid having to show all kinds of details that don’t do
anything essential (or essentially different), I’m showing two business rules that are a bit simpler
than the ones above. They’re still actual business rules, though.
Figure 1.3 Two simple business rules, as seen in the Domain IDE
This figure shows two business rules that check the period of the intended rental, and apply
discounts based on whether their conditions holds. As an example: if the rental period lasts from
December 4th until December 10th 2020, the customer should be given a discount of 15%,
because that period contains both a Saturday, and starts in December. Let’s put in some more
explanation:
©Manning Publications Co. To comment go to liveBook
https://livebook.manning.com/#!/book/domain-specific-languages-made-easy/discussion
