liveBook · Manning

Domain-specific language content

As explained in Building User-Friendly DSLs

Structured domain-specific information, including the rules, structures, and expressions represented in a domain-specific language.

Domain-specific language (DSL) content is the structured representation of domain knowledge written in a DSL. It captures concepts such as record types, attributes, business rules, conditions, actions, and expressions in a form that domain experts can understand and maintain. Rather than serving as a free-form requirements document, it is precise enough to act as a specification for the software system. section 1.2 section 1.3.4

A Domain IDE lets domain experts create and revise this content through domain-meaningful interactions. Editing is structured rather than character-by-character: the editor can offer valid operations or constructs, guide choices, render different parts distinctly, and report errors. Those constraints make the content easier to write correctly while preserving a readable business-facing notation. section 1.2.1 section 1.4.1

Rental pricing rules

Car-rental content can state that a rental receives a discount when its date range contains a Saturday and begins in December. A rental from December 4 through December 10, 2020 satisfies both conditions and receives a 15% discount. Other rules can apply holiday surcharges, week-long-rental discounts, or environmental fees. section 1.2.1 section 1.2

DSL content has operational meaning through what it produces. Record types and business rules can be transformed into code, used to build the Runtime, and observed through that Runtime’s behavior. In this approach, the behavior produced across possible content defines the DSL’s meaning. section 1.4.3 section 1.2

Content must evolve with the domain, so its management needs to support domain-expert workflows:

  • Collaborate synchronously through real-time editing or asynchronously through a distributed version-control workflow. section 10.4 section 10.1
  • Represent projectional-editor changes as small deltas on the abstract syntax tree (AST). section 10.4
  • Annotate content with a DSL version ID; check compatibility when loading it and migrate it when versions differ. section 10.4
Figure 1.2 Using a DSL-based approach to develop a Runtime using a Domain IDE
figure

Shows the flow in which domain experts author DSL content in a Domain IDE and the resulting software Runtime is built from it. section 1.2

How Building User-Friendly DSLs covers it

How deep it goes
Explains authoring, structured editing, generated meaning, collaboration, version checks, and migration rather than generator implementation details.
Examples
Uses car-rental record types and discount, surcharge, and environmental-fee business rules as content examples.
What it assumes
Introduces DSL content through business knowledge and concrete rules without assuming advanced DSL or compiler knowledge.
What you can do after
Operate/configure it by authoring, collaboratively changing, versioning, and migrating structured domain knowledge in a Domain IDE.
How it connects
Connects DSL content to Domain IDEs, DSL notation, projectional editing, abstract syntax trees, code generation, and version control.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building User-Friendly DSLs. The section links point to the parts of the book it draws on.