A constraint is a condition that DSL content must satisfy to be meaningful and safe to process. It queries an AST for patterns that would make code generation, building, or Runtime execution fail or produce meaningless results. A violation makes the AST invalid, also called inconsistent, and is reported near the offending content as a helpful issue. section 1.4.4 section 9.1 section 9.4
Figure 1.22 Zooming in on the constraints aspect of a DSL
This diagram situates constraints between DSL content and the Domain IDE feedback that warns domain experts before downstream failures occur. section 1.4.4
Use constraints as the first response to failures caused by AST contents: identify the faulty pattern, formulate the condition that rules it out, and show an issue explaining what to repair. A clean issue report is intended to support a strong boundary: when the Domain IDE reports no issues, the generator should finish, the Runtime should build, and execution should not crash or become meaningless. Invalid ASTs may still be saved and shared because editing naturally creates temporary invalid states and reproducible bug reports need the original content. section 9.1 section 9.2.1
Flagging an unnamed rental attribute
Adding a Data Attribute without a name leaves its name setting undefined. The generator then passes that value to camelCase and crashes on toLowerCase. A checker can require a nonempty string name, return “An attribute must have a name,” and let the projection display a warning marker and tooltip on that attribute. The generator can also be hardened to emit a recognizable generation-problem placeholder rather than crash. section 9.2 section 9.2.2
Constraints can range from local checks to AST-wide consistency checks:
- Check unspecified content, such as an attribute with no name, type, or completed value. section 9.2.2 section 9.4
- Check type compatibility across related content and uniqueness of sufficiently similar neighboring names. section 9.4
- Navigate attribute references to find cycles that would make dependency ordering loop indefinitely, then name the cycle in the issue. section 9.3.5
Do not treat every bad result as a constraint problem. Missing default handling for otherwise valid types is incomplete template code and should be fixed in the generator. More generally, pair ImposeConstraints with HandleFaultyContent when practical: constraints tell domain experts what is wrong, while defensive generation limits crashes and can flag incorrect generated code. Preventing persistence of incomplete content is another option, but it trades away the ability to save work in progress. section 9.2.1 section 9.3.1 section 9.4
Changing constraints changes what counts as a valid AST and therefore how many issues domain experts see, without changing DSL structure. Widening an accepted property type loosens a constraint; narrowing it adds or sharpens one to prevent wrong generated code or generator failure. section 10.3.4
