The Polymorphic Domain Specific Language design pattern is used to make it possible to develop or test modern applications which are otherwise unable to be handled in a scalable, maintainable way.
This is a particular necessity with the advent of distributed systems or the need to support multiple clients and platforms. A typical web application often has 2 native mobile applications developed for it as well. This creates a problem: to add or test 1 feature it takes n units of work, where n is the total number of clients, platforms or services.
The reality is that conventional approaches do not scale. In a conventional distributed system dozens or hundreds of microservices are the norm. Quite often these services have functions of shared concern. For example, a store may have several APIs to update inventory. They may provide an endpoint for updating in bulk, one at a time through a UI and several other mechanisms suitable for different use cases. However they are all ultimately doing the same thing.
In a situation like this development becomes highly error prone. Adding a very simple feature such as changing the maximum length of a required field might only be implemented one or a small subset of the services that handle that field. The other services might only become discovered after deploying the feature breaks one of the many services people couldn’t keep track of. Rollbacks might become a common operation for what appeared to be simple work that actually had a complex web of interactions between services.
The PDSL pattern elegantly resolves these sorts of problems and provides a variety of other desirable benefits that make it suitable for even the most demanding applications.
At it’s heart the basic idea is to create a common protocol or language to describe your application or its data that is platform and language agnostic. Once this loose external coupling is achieved then the application can be either developed or tested using this grammar.
In one sentence, Polymorphic DSl is:
A Domain Specific Language used to specify what to do in a way everybody understands that everybody does in their own way.
A basic model has four layers of architecture:
-
Domain Specific Language
-
Specification Language
-
Interface Definition Language
-
Client
The Domain Specific Language is a common protocol used to describe things.
The Specification Language is structure or data collection made from the Domain Specific Language that says what to do.
The Interface Definition Language translates the specification in a way everybody understands.
Then the client does the work in its own way.
Imagine a country with several states that speak their own language (a common occurrence historically). A successful author becomes famous for writing fabulous stories and wants to write books that everyone in the nation can read. So the author writes a new book and translates it into 12 different languages.
At first everything is okay, but later a typo is discovered that made it into all translations. The author then pays to translate the fix 12 times.
After most of a lifetime the author has produced many books. A civil war breaks out and a new state is formed in the nation. This state has yet another official language. The author is faced with the grim prospect of translating a lifetime
Eventually everyone in the country gets fed up with this kind of trouble and decides to talk to each other in a common contact language that everyone can understand. From now on whenever members from different states interact with each other they simply talk using the common language. A book only needs to one time and everybody know what to do. Communication is cheaper and the cultural barriers that prevented people from feasibly working together are removed.
Some overviews with analogies that might be more familiar to specific roles are provided below