Domain Specific Languages

Domain Specific Languages (DSLs) are a relatively new trend related to Model Driven Development, Model Driven Architectures etc.

Design Remarks

Define Domain and Depth

It is important to define the domain of a DSL (obviously), and also to which depth the domain should be modelled. At the shallowest depth, a DSL is just a controlled vocabulary to describe a domain specific state, and some syntactic structure on the vocabulary elements. This corresponds to class diagram like models, such as those provided by the Eclipse Modelling Framework (EMF). DSLs at greater depth capture domain specific behaviour. Changes in depth and in behaviour frequently entail large scale changes in the design of a DSL (and the APIs supporting its implementation). From this perspective, decisions on DSL depth can be considered architectural decisions, as they are difficult to change once the DSL is realised.

Use Object Orientation With Class Names and Object Names

Where possible, DSLs should use basic object oriented patterns. Specifically, clearly indicating the class of each object in the DSL's object notation is very useful for human reading, parsing and transforming the DSL. Object names (or identifiers) incur some overhead and potential nuisance as they have to be kept unique. However, they are very useful to formulate operations on the DSL, which otherwise have to depend on unsafe and / or ad-hoc approaches, such as indexing. Notice that object names are not to be confused with variable names, as multiple variables can refer to the same object. From this perspective, JSON is a bad DSL (or template for DSLs), as it provides neither class names nor object names.

Misc Remarks

• DSLs are frequently supported by an API and enable non-programmer user types to work with that API.
• DSLs frequently mediate design of user interfaces