3 Kinds of DSL's

In my experience, there are at least 3 use cases for DSLs:

• DSL used by an engine for configuration / data
• declarative: lets users focus on the "what" and standardizes the "how"
• DSL used for code generation
• DSL used for expression syntax
• procedural: focuses on letting users express the "how" 

I have experience with the first two, the third has been on my "todo" list for quite some time, it's just I have never had the need to make my own expression syntax.  

https://pragprog.com/titles/tpantlr2/the-definitive-antlr-4-reference/

As for the first two:

1. DSL used by engine for configuration / data. 

This variant seems to be what I keep going back to as my "goto" pattern for abstraction.  I have outlined the process in earlier posts. 

https://jmenke.blogspot.com/2019/05/iterative-refactoring-and-emergence-of.html

The key is understanding the flow of your processes, after that its a matter of abstracting out the parts that change into the DSL.  It's the parts that remain constant that end up in the engine.   

2. DSL used for code generation

This is useful for bootstrapping application code bases.  I have used this a few times to make templating engines for families of applications.  The XText tool is particularly useful in this use case and related modeling tools in the Eclipse platform open the door to created graphical DSLs using many of the same tools.  Note this is usually a one time operation as supporting future edits and full round trip capability between the generated code and the base code requires much more effort.

It seems Kubernetes uses the 1st option. 

The yaml configuration along with operators and CRDS define configuration / runtime data that is processed by an engine ( the operator ).   This is the type of DSL that is envisioned for configuring the Data, Resource, Routing and Execution parts of the Uber language of compute.