Wednesday’s session about the DSL tools for Model-Driven Development in VS2005 was truly fascinating. Actually, I think that it justifies the investment of my trip across the Atlantic alone!

After illustrating that domain specific languages are ways to improve effectiveness in communication, Jochen Seemann literally blew my mind by demonstrating what can be done today with the CTP release version of the upcoming Microsoft Domain-Specific Language (DSL) Tools.

This SDK allows you to easily build a graphical designer hosted by Visual Studio 2005 that is able to provide support for a custom domain-specific language.

What does it mean? Once the designer is built, a user can instantiate the designer, drag custom shapes from the toolbox, connect those shapes together (with validation support according to the language rules) and use the template engine to generate code/artifacts!

Building a DSL designer requires several steps, which basically involve the definition of:

• the elements of our domain in a domain model (classes and relationships)
• the notational elements (shapes and connectors) for the business entities
• the legal rules (validation/constraints) from a notational perspective, and the mapping of the notation to the elements of our domain.

Once the designer is built and instantiated we can use template-based generators to generate artifacts from our model (e.g. code, HTML, XML, WordML, etc). The templates have a notation similar to CodeSmith or classic ASP, and in the future some form of Intellisense (to query the model) is likely to be provided.

Some of these steps currently require the editing of an XML file. However Jochen said that this is really an “alpha” version of the toolkit and that better support will be provided in further iterations (indeed, the textual generator engine, code named T4, is only 6 weeks old!).
He plans to release incremental versions of the toolkit every 2-3 months, maybe even after version 1.0 will be shipped.

Currently I have only a few random observations/considerations on DSL designers that I want to dump here for my reference and eventually refine in future posts as I become more experienced in this field:

• We can build multiple designers to generate different parts in our systems, so we can (and probably should) start small.
• 2-Way synchronization (e.g. graphical model – to generated code – back to graphical model) is probably not going to be provided with version 1.0. It is a difficult problem to solve and I agree with Jochen’s pragmatism that it would be a fundamental feature only in a relatively small number of cases.
• Template/designer versioning and deployment are going to be difficult issues. We will need a defined structure and guidelines to avoid dealing with a total mess.
• A DSL designer is likely to work effectively in areas when the domain entities are very well understood. I can see how the use of a ubiquitous language would be core in this context.
• DSL designers could be used for requirements; however I have some reservation in this direction as the domain model is likely to be refined and changed way too quickly in a real world scenario. Use cases, CRC cards, and UML drafts are still likely to be my preferred option in the short term. I might be totally wrong on this, and I hope somebody can change my ideas soon (any volunteers?).
• There is a space for graphic tools and a space for code. A guy asked if Microsoft was going to provide basic notational elements that would give us very fine grained control capabilities (ifs, whiles etc). I think that writing code using shapes is insane. This is not a new idea (companies have been trying for years to propose solutions in this direction) but when you get pages and pages of icons you quickly realize that you are in the wrong space.
• Code generation driven by a designer is very cool. However writing templates is a pain and it feels like going back to messy scripting languages.
• Aspect Orientation could have a major role in this type of development. You add an attribute to a shape and (with the right template) your code magically gets to be generated. Jochen is not totally convinced by the feasibility of the AO approach as many people got burned. After talking to the guys in Avanade, however, I’ll be willing to take a serious shot in my problem space.
• It will be fundamental to maintain a clear separation between generated code and custom code. Use of partial classes that can be regenerated would be an option, separate classes and aggregation/inheritance another.
• I wish we could have several injection points in the designer and even a link to MSBuild, so that separate tasks could be executed upon code generation.

I hope this post gave you a sense of what this technology can provide. As I said at the beginning, I’ve been totally fascinated by it.
Finally let me just say that this technology gave me a fantastic idea that promises to provide an incredibly elegant solution to a huge problem in Innerworkings’ domain. Unfortunately I’m only teasing you guys because I can’t tell you what it is, as probably Fran (my CEO) would literally kill me if I did 🙂