A domain-specific language (DSL) is a precisely defined software language for expressing knowledge in one focused domain. Unlike natural language, its notation has unambiguous meaning and software tools can process what its users write. It is neither a general programming language nor a general modeling language, although it shares characteristics with both. section 1.1 section 1.5
A DSL begins with a domain’s ubiquitous language: the specialized terms and notations domain experts use while speaking and writing about their work. Turning that pre-DSL into a software language requires identifying its core concepts, defining them precisely, choosing suitable notation, and providing tools to author and process the resulting DSL content. section 1.4
A usable DSL combines four connected aspects:
- Notation is the visual system for writing DSL content. It may be textual, graphical, or mixed, but usually uses a small set of recognizable visual building blocks. section 1.4.1
- Structure defines concepts, their typed properties, and relations. DSL content consists of instances whose settings provide property values. section 1.4.2
- Meaning comes from what generated software does with the DSL content; in a DSL-based approach, content helps determine Runtime behavior. section 1.5
- Constraints detect structurally possible but nonsensical content and let the editor warn users before code generation or execution fails. section 1.4.4
In a DSL-based approach, domain experts use a Domain IDE rather than write free-form specifications for developers to translate manually. The IDE lets them author guided DSL content that is understandable and maintainable for them, while its backend stores content and generates and builds substantial parts of the required Runtime. Developers build the IDE and the parts of the Runtime that cannot be specified in the DSL. section 1.2 section 1.5
Car-rental pricing rules
A car-rental domain can express rules such as applying a 10% surcharge when a rental period contains a national holiday, giving a 5% discount beyond a week, or charging an environmental fee for a gas guzzler. These domain rules become precise, processable DSL content rather than ambiguous prose. section 1.1 section 1.4
Table 1.2 Criteria for judging when a DSL-based approach could be helpful
|
•
|
The domain is a business domain.
|
|
•
|
The business knowledge to be specified is of considerable size.
|
|
•
|
Any piece of knowledge has plenty of detail, with complicated relationships and connections between pieces.
|
|
•
|
The specification will be written by more than one person.
|
|
•
|
The specification will be based on a set of clearly identifiable
concepts that are applied consistently. A concept is a construct with a specific and clearly defined meaning. In our car rental example, we already have the following concepts: business rule, condition, action, record type, and attribute.
|
|
•
|
The specification contains a lot of expressive business logic, along the lines of “When the customer has paid interest in every of the last 12 months, they are eligible for a discount of 10% on the interest of the next month.” Award bonus points if this business logic is naturally or comfortably expressible using business rules.
|
|
•
|
The specification is dynamic: it changes often, and these changes must be propagated to the Runtime quickly.
|
|
•
|
There’s a potentially complicated, but clear, path from pieces of the specification to pieces of code for the Runtime. This implies it’s possible to implement a generator.
|
Use the criteria table to judge whether a sizeable, detailed business specification with recurring concepts and expressive logic is a promising DSL candidate. section 1.3.4
A DSL-based approach is useful when a business domain has substantial, detailed knowledge, multiple specification writers, consistent concepts, and expressive business logic. It can reduce error-prone communication between domain experts and developers, automate repetitive implementation work, and make specifications machine-checkable and testable near the knowledge they validate. It is not automatically the right choice for every situation. section 1.3.3 section 1.3.4
One implementation path uses projectional editing: a projection renders structured DSL content in a browser, then gains editing behavior to become a DSL editor. This treatment builds such tooling from mainstream technologies and covers ASTs, code generation, expressions, type systems, constraints, and DSL evolution; it deliberately does not teach textual parsing-based DSLs or internal DSLs in depth. section 1.2.3 section 1.4.1
