In the software development industry, we need to solve problems we encounter every day. To define the solution for a given problem, we use some programming languages and usually the solution consists in a piece of software.
Problems and solutions can vary, but very often we see that some of them are repetitive and this can create frustration for developers. For such cases, developers came up with some generic approaches in either design patterns or architectural solutions. However, even in this case, repeating the same architectural solution can be frustrating and time consuming. In this context, some of the developers come out with a new solution in the area of Domain-Specific Language - a way to create new languages which are focused to resolve small and well regulated problems from a given domain, making it easier for development work.
A Domain-Specific Language (or DSL for shorter) is a programming language that's targeted at a specific problem or, in other words, it is a computer language only applicable to a particular application domain.
In general, many of the software solutions are developed using a general-purpose language (GPL) such as Java, C#, C++ etc. In contrast, a DSL is tightly bound to a particular application domain, so it relies on creating a very good abstraction of that problem. In many situations it is easier to use a DSL because it models the problem and all the business rules very well, making the solution very easy to be achieved and much less error prone.
The concept of Domain-Specific Language was created based on the observation that many problems faced by software applications can be solved easier by designing a specially purposed language. A small example can be "finding occurrences of a particular pattern of characters in a text". For this simple problem a specially purposed text language known by all developers as "regular expressions" was created.
A way to resolve a class of similar problems is to define and use a Domain-Specific Language instead of using a general-purpose programming language. One of the advantages of using DSLs is that you can define a good structure of terms and actions for a given class of problems. Now let's talk about how many forms of DSLs we can either find or implement ourselves. 2
Just like any other languages, Domain-Specific Languages can come under multiple forms. Depending on the problem we need to solve, by employing a DSL, we can use a textual form language or a visual/graphical one.
Let's see first how a textual language looks like, as the form expressing the textual defined DSL is a text having some keywords and a very good structure to abstract a given domain problem. The text is written, then analyzed and transformed based on some predefined algorithms and rules in order to become an artifact. After this, the artifact (which can be something from a little piece of code to a whole application) can further be used in the problem solving process or any other processes.
An example of a textually defined DSL is Gherkin. Gherkin is a DSL for defining functional tests. It has a very flexible syntax that makes it look almost like free text. Basically, developers, analysts and clients can sit around a table and define some scenarios. These scenarios will then be executed as tests, to verify whether the application meets their expectations.
Here it is how we could define the expectations for withdrawing from an ATM:
Scenario: Verify withdraw at the ATM works correctly
Given John has 500$ on his account
When John ask to withdraw 200$
And John inserts the correct PIN
Then 200$ are dispensed by the ATM
And John has 300$ on his accountExemple from: https://tomassetti.me/domain-specific-languages/
Another well-known DSL is SQL. It is a language used to define how to insert, modify or extract data from a relational database. Let's get some stats from the STATS table:
SELECT [Id], [Title], [Author], [Publisher],
[Description] FROM [BookStore].[dbo].[Books]The other way to define a DSL is to use a visual/graphical form. This means that the domain is defined as some visual representation, in many cases as different geometrical figures.
Both graphical and textual languages have their advantages and disadvantages, but each of them can be used for a very specific category of problems.
However, graphical languages have more advantages than the textual ones because they provide a visual representation of a domain problem by the shape of a diagram, which can be understood much easier. Yet, each person can prefer one form or the other for a DSL representation.
The textual representation is preferred by some people because they can type very fast and because they can compute the difference between two files.
The graphical representation of a DSL is better for diagrams. The diagram approach is better when we see the "overall picture" of the problem represented by language. Diagrams provide a better way for us to visualize the relationships among entities. 3
Each of the ways which define a DSL have their pros and cons, but they all share a common theme - they define a language that makes it easier for us to solve very specific problems extremely fast.
Using DSLs can reap a multitude of benefits. Once you've got a language for a particular aspect of your development task, work becomes much more efficient, simply because you don't have to do the work manually. This is the most obviously useful thing - IF you can replace a lot of general purpose language code with a domain specific language form. Another benefit of using a DSL is that the quality is increased because we have fewer bugs, a better architecture conformance and increased maintainability.
One great benefit is also the fact that the validation of the output implementation gets easier - because the domain-specific aspects are uncluttered, the manual review and validation become more efficient.
Not less important in this process is that domain experts can be involved more directly. DSLs whose domain, abstractions and notations are closely aligned with how domain experts (non-programmers) express themselves, allows for a very good integration between developers and domain experts.
The Domain-Specific Languages are small languages designed and implemented for a particular domain of application. These languages help the implementation of solutions for that particular domain by abstracting the problem and simplifying the solution.
They come under two main forms: a textual form which is basically a text with well-defined semantics, and a visual/graphical form which is represented by well-chosen (representative) visual elements.
We also have multiple advantages by using these kinds of languages: due to the fact that they are based on a very good domain model, the development process is improved. Basically, from reducing the time of solving a problem and reducing the number of bugs to improving the overall collaboration between developers and domain experts, DSLs are an excellent option to shape implementation processes.
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison Wesley, 2003.
Stuart Kent, Steve Cook, Domain-specific development with Visual studio DSL tools, Addison-Wesley Professional, 2007.
by Andrei Oneț
by Raul Boldea
by Paul Bodean , Eugen Meltis
by Dan Sabadis
