Domain-Specific Development

Visual Studio 2008

Updated: July 2008

Domain-specific development is the process of identifying the parts of your applications that can be modeled by using a domain-specific language, and then constructing the language and deploying it to the application developers. The developers use the domain-specific language to construct models that are specific to their applications, use the models to generate source code, and then use the source code to develop the applications.

A graphical domain-specific language must include the following features:

  • Notation

  • Domain model

  • Artifact generation

  • Serialization

  • Integration with Visual Studio


A domain-specific language must have a reasonably small set of elements that can be easily defined and extended to represent domain-specific constructs. A notation consists of shapes, which represent the elements, and connectors, which represent the relationships between elements, on a graphical diagram surface. In Domain-Specific Language Tools, the shapes can be extended and refined to represent the elements of your domain-specific language.

Domain Model

A domain-specific language must combine the set of elements and the relationships between them into a coherent grammar. It must also define whether combinations of elements and relationships are valid. For example, programming languages typically prevent circular inheritance, in which one class is derived from a second class and the second class is derived from the first class. Constraints can also be used to express business logic, for example, one person cannot be a dependent of himself. Domain-Specific Language Tools uses constraints to express the kinds of restrictions that most domain-specific languages require.

Artifact Generation

One of the main purposes of a domain-specific language is to generate an artifact, for example, source code, an XML file, or some other usable data. Typically, a change in the model means a change in the artifact. You can use Domain-Specific Language Tools to generate artifacts and to regenerate them when you change the model.


A domain-specific language must be persisted in some form that can be edited, saved, closed, and reloaded. Domain-Specific Language Tools uses an XML format that lets you define and customize how your domain-specific language is serialized (or persisted).

Integration with Visual Studio

Because Domain-Specific Language Tools is hosted in Visual Studio, it extends many Visual Studio windows and controls. It also lets you customize the behavior of menu commands, toolbox items, and other elements of the user interface.

A domain-specific language can provide the following benefits:

  • Contains constructs that exactly fit the problem space.

    Unlike general-purpose languages, a domain-specific language consists of elements and relationships that directly represent the logic of the problem space. For example, an insurance policy application must include elements for policies and claims. A domain-specific language makes it easier to design the application, and find and correct errors of logic.

  • Lets non-developers and people who do not know the domain understand the overall design.

    By using a graphical domain-specific language, you can create a visual representation of the domain so that non-developers can easily understand the design of the application.

  • Makes it easier to create a prototype of the final application.

    Developers can use the code that their model generates to create a prototype application that they can show to clients.

Most software development teams that use domain-specific languages follow these steps to create and use their models:

  • The team distinguishes the variable parts of the domain from the parts that never change.

  • The developers write code for the fixed parts and leave extension points for the variable parts.

  • The software lead or architect creates a domain-specific language that incorporates the design patterns of the fixed parts of the domain and the extension points for the variable parts.

  • The lead or architect deploys the domain-specific language to the developers of the various applications that the team produces.

  • Every developer creates a model that applies to the specific application.




July 2008

Rewrote and refactored project.

Content bug fix.

Community Additions