Domain-Specific Development: Introduction

This book describes the Microsoft Domain-Specific Language Tools (the DSL Tools). The DSL Tools are part of the Visual Studio SDK, and may be downloaded from http://msdn.microsoft.com/vstudio/DSLTools/. The DSL Tools extend Microsoft Visual Studio 2005 to support a powerful way of developing software called Domain-Specific Development.

Domain-Specific Development is based on the observation that many software development problems can more easily be solved by designing a special-purpose language. As a small example, think about the problem of finding every occurrence of a particular pattern of characters in a file, and doing something with each occurrence that you find. The special-purpose textual language of regular expressions is specifically designed to do this job. For example, using the .NET class System.Text.RegularExpressions.Regex, the regular expression (?<user>[^@]+)@(?<host>.+) applied to a string of characters will find email addresses in it, and for each address found, assign the substring immediately before the @ sign to the user variable, and the substring immediately after the @ sign to the host variable. Without the regular expression language, a developer would have to write a special program to recognize the patterns and assign the correct values to the appropriate variables. This is a significantly more error-prone and heavyweight task.

Domain-Specific Development applies this same approach to a wide variety of problems, especially those that involve managing the complexity of modern distributed systems such as those that can be developed on the .NET platform. Instead of just using general-purpose programming languages to solve these problems one at a time, the practitioner of Domain-Specific Development creates and implements special languages, each of which efficiently solves a whole class of similar problems.

Domain-Specific Languages can be textual or graphical. Graphical languages have significant advantages over textual languages for many problems, because they allow the solution to be visualized very directly as diagrams. The DSL Tools make it easy to implement graphical DSLs, and they enable Domain-Specific Development to be applied to a wide range of problems.

Domain-Specific Development

Domain-Specific Development is a way of solving problems that you can apply when a particular problem occurs over and over again. Each occurrence of the problem has a lot of aspects that are the same, and these parts can be solved once and for all (see Figure 1-1). The aspects of the problem that are different each time can be represented by a special language. Each particular occurrence of the problem can be solved by creating a model or expression in the special language and plugging this model into the fixed part of the solution.

The fixed part of the solution is written using traditional design, coding, and testing techniques. Depending on the size and shape of the problem, this fixed part of the solution might be called a framework, a platform, an interpreter, or an Application Programming Interface (API). The fixed part captures the architectural patterns that make up the domain and exposes extension points that enable it to be used in a variety of solutions. What makes the approach applicable is the fact that you create the variable part of the solution by using a special-purpose language—a DSL.

As we observed in the introduction, the DSL might be textual or graphical. As the technology for domain-specific development matures, we expect to see tools that support the development and integration of both textual and graphical DSLs. People have a range of feelings about which kind of language they prefer. Many people, for example, prefer textual languages for input, because they can type fast, but graphical languages for output, because it is easier to see the "big picture" in a diagram. Textual expressions make it much easier to compute differences and merges, whereas graphical expressions make it much easier to see relationships. This chapter discusses both kinds, but the first version of DSL Tools and hence the remaining chapters of the book focus solely on graphical languages.

To create a working solution to the problem being addressed, the fixed part of the solution must be integrated with the variable part expressed by the model. There are two common approaches to this integration. First, there is an interpretative approach, where the fixed part contains an interpreter for the DSL used to express the variable part. Such an approach can be flexible, but it may have disadvantages of poor performance and difficulty in debugging. Second, the particular expression or diagram may be fully converted into code that can be compiled together with the remainder of the solution—a code-generation approach. This is a more complex conversion procedure, but it provides advantages in extensibility, performance, and debugging capability.

Graphical DSLs are not just diagrams. If you wanted just to create diagrams, you could happily use popular drawing programs such as Microsoft Visio to achieve a first-class result. Instead, you are actually creating models that conceptually represent the system you are building, together with diagrammatic representations of their contents. A given model can be represented simultaneously by more than one diagram, with each diagram representing a particular aspect of the model, as shown in Figure 1-2.