Modelling with Domain-Specific Languages


With the entire industry moving as quickly as it has been for the past few years, it is not surprising that every once in a while you discover a technology or capability that has been around for a number of years yet has escaped your attention.

Domain-Specific Languages (specifically the implementation within Visual Studio) has been one of those cases for me, but over the past few weeks I’ve been spending my spare time playing with the models and considering its role in the production (primarily) of design documentation. I’m always on the look-out for ways to improve communication with members of the customer’s team and one thing is obviously true – it doesn’t matter whether they are managers, business users, or analysts – pretty pictures do a great job of communicating complex ideas simply.

I can almost hear you saying now ‘but Domain-Specific languages have been around for years (since VS2005 in fact) … so how is it that this is new to you!’ Well I was feeling pretty embarrassed about that, until I presented the concept internally to some of my colleagues at work and found that no-one else had investigated DSL either. Now I don’t feel so bad.

So for those readers who haven’t used DSL in the past, it’s probably safe to say that you’ve at least used the models produced using the toolkit. The DSL modelling SDK is responsible for many of the graphical designers within Visual Studio, such as;

  • The Visual Studio Architecture Tools
  • The Entity Framework designer
  • The BizTalk ESB Toolkit Itinerary designer
  • The Web Services Software Factory designer

Why I’m Excited

Generating a nice diagram is well and good – but the fact is Visio can do that. The power of the DSL SDK comes with the extensibility – some of the features that have me interested are;

  • Customized Rules and Validation. This is key to help new team members understand the model
  • Model Generated meta-data generation. A lot of data we deal with is meta-data that ultimately needs to be loaded into a database, or system of some form.
  • Model Generated design documentation. I’m quite excited about the idea of transforming (using the Visual Studio’s T4 templates) the model xml into Word XML or similar.
  • Distributable. As most models can be executed within Visual Studio Shell, they could easily be shared with business analysts and customer representatives who might not already have Visual Studio.

On top of this, model development is fast! Without writing any code at all it doesn’t take long to produce a model. Models could easily be built for short-lived project requirements.

Getting Started

As with any technology that has been around for seven years already, there is some good material on the internet for getting started, and I’m not trying to replicate that in this post.

A Basic Example

As an example, consider for a moment the process of defining document libraries in a SharePoint environment. This often involves defining a Content Type for the library, configuring the document library (possibly with additional library-specific columns), and possibly adding an approval workflow.

The Domain Class model below outlines three core types (note I’ve hidden some of the relationships from simplicity here);

  • Content Types, including;
    • Embedded relationship to Columns
  • Document Libraries, including;
    • Embedded relationship to Columns
    • Reference relationship to Content Type
    • Reference relationship to Workflow
  • Workflows, including;
    • Several Domain Properties defining attributes for workflow configuration

Each of these Domain Classes have been mapped to Component Shape and Connector elements to support the visualization of the model.

The resulting model allows users to graphically model the Content Types, Document Libraries and Workflows required for the solution, resulting in the following diagram. In this case I’ve shown Content Types in purple, Document Libraries in orange and Workflows in lime green. As you can see, this provides a high-impact top level view of the domain model, and is well suited to including in design documentation communicating the solution to customers, developers and maintenance teams alike.

While the design process is being conducted, it is often simpler to capture any additional details required for the solution being developed at the same time – this is where diagrams in Visio start to fall short a little. Since the DSL model is hosted within Visual Studio, we have full access to the property grid – so all custom Domain Properties can be captured simply.

To extend this example a little further, consider the possibilities of artifacts that could be generated from this model such as;

  • Automation of web service calls to implement the content types / libraries and workflows directly from the model
  • Generation of Word tables containing the properties stored against each Domain Class. This could include the detailed attributes from the property grid that are not shown in the visualization.