In a domain modeling activity, the problem domain is the processes, entities, and constraints that are part of the business that you’re analyzing.
Domain modeling, also known as domain analysis (see [1] in section 1.9), involves the identification of all the major components of the domain and how they collaborate. (查看原文)
A DSL is a programming language that’s targeted at a specific problem; other programming languages that you use are more general purpose.
It contains the syntax and semantics that model concepts at the same level of abstraction that the problem domain offers.
Programs that you write using a DSL must have all the qualities that you expect to find in a program that you write in any other computer language.
A DSL needs to give youthe ability to design abstractions that form part of the domain.
In the same way that you can build a larger entity out of many smaller ones in the problem domain, a well-designed DSL gives you that flexibility of composition in the solution domain.
You should be able to compose DSL abstractions just like you compose your functionalities in the problem domain... (查看原文)
A DSL is targeted at a specific problem area
A DSL contains syntax and semantics that model concepts at the same level of abstraction as the problem domain does (查看原文)
When you program using a DSL, you deal only with the complexity of the problem domain.
You don’t have to worry about the implementation details or other non-essential elements of the solution domain. (查看原文)
More often than not, people who aren’t expert programmers can use DSLs—if the DSL has the appropriate level of abstraction.
Mathematicians can easily learn and work with Mathematica, UI designers feel comfortable writing HTML, hardware designers use VHDL (very-high-speed integrated circuit hardware description language; a DSL used in electronic design automation) to name a few such use cases. (查看原文)
The key issue is communication, the ability for your program to communicate with its intended audience.
In the case of a DSL, the direct audience is neither the compiler nor the CPU, but the human minds that need to understand its behavior. (查看原文)
A DSL provides a direct mapping to the artifacts of the problem domain.
If the problem domain has an entity named Trade, the DSL script must contain the same abstraction that plays the same role.
The DSL script must use the common vocabulary of the problem domain.
The vocabulary becomes the catalyst for better communication between developers and business users.
When business users interact with the software domain model, the DSL script is their interface, as shown in figure 1.3.
The DSL script must abstract the underlying implementation. This principle is an important part of good abstraction design, and it applies to DSLs as well.
The DSL script cannot contain accidental complexities that deal with implementation details. (查看原文)
In most cases, a DSL is nothing but a layer of abstraction over the
host language that presents a domain-friendly interface to the business users.
(It’s not always the host language. See section 1.5 for details about DSL classification.)
You’re kind of extending the host language to implement another language on top of it.
This concept is sometimes referred to as a metalinguistic abstraction. (查看原文)
The script can directly execute the underlying model without any more code generation or manipulation.
There might be an interpreter that directly interprets the script and runs it. The UNIX little programming languages awk and sed are examples of DSLs that execute directly.
A DSL script that’s developed on a virtual machine follows the second model.
The semantic model underlying any Java DSL script generates bytecodes that
are executed on the JVM.
Some languages offer compile-time metaprogramming.
When you’re developing a DSL using this kind of language, you build metastructures as part of your source code, which get translated to the normal forms of the language before it runs.
Lisp supports this technique through macros that get expanded to normal Lisp forms during the macro expa... (查看原文)
An internal DSL is one that uses the infrastructure of an existing programming language (also called the host language of the DSL) to build domain-specific semantics on top of it.
In most cases, an internal DSL is implemented as a library on top of the existing host language.
As you see in figure 1.5, the internal DSL script is a thin veneer over the abstrac-
tions of an underlying host language. (查看原文)
An external DSL is one that’s developed ground-up and has separate infrastructure for lexical analysis, parsing techniques, interpretation, compilation, and code generation.
Developing an external DSL is similar to implementing a new language from scratch with its own syntax and semantics.
Build tools like make, parser generators like YACC, and lexical analysis tools like LEX are examples of popular external DSLs.
Of course, the complexity of an external DSL implementation depends on how rich you want it to be. (查看原文)
Generative—Domain-specific constructs are transformed to generate code through compile-time macros, preprocessors, or some form of runtime meta-object protocol (MOP).
Embedded—Domain-specific types are embedded within the type system of the host language. (查看原文)
External DSL design follows the same lifecycle and principles of general-purpose language design.
Although the statement is true in theory, it’s not all that grim when you consider that your DSL isn’t necessarily as complex in syntax and semantics as a general-purpose programming language can be.
In reality, you can process some external DSLs by manipulating strings using regular expressions. But the only common trait of all external DSLs is that they aren’t implemented using the infrastructure of a host language. (查看原文)
Parse—where you tokenize the text and use a parser to recognize valid inputs
Process—where you do the business processing on valid inputs that were recognized by the parser in the first phase (查看原文)
