DSLs—also known as domain-specific modeling languages—are more expressive and therefore tackle complexity better, making modeling easier and more convenient. More importantly, they allow automatic, full code generation, similar to the way today's compilers generate Assembler from another programming language.

Domain-specific modeling (DSM) puts models at the core of development, making it truly model-driven. Of key importance is the ability to define and maintain your own DSL. In my opinion, model-driven development works best if the language really is domain-specific: Ideally, the language is limited to just one company or even one development area in that company.

If there are no compromises in the syntax of your design language, there need to be no compromises in the way you generate artifacts from designs in that language. This is the true essence of model-driven development and the path to the biggest productivity and quality improvements. A carefully executed and narrowly defined DSL can reap an order of magnitude improvement in productivity and quality.

The problem that companies—or rather their expert developers—will face is how to come up with a suitable DSM language. It is very likely that defining a new modeling language is not part of their current skill-set. Most developers know that they can achieve the biggest benefits by raising the abstraction level of the modeling language. However when given the task to create such a language for the first time, it is relatively easy to end up with a language that reflects the code they normally write. Such a language does not raise the level of abstraction, and limits the possibility for increasing productivity with generators.

In this article, I will draw upon 15 years of experience in this field to provide some guidelines for creating an effective DSL. I will focus on modeling languages that go beyond documentation, targeting full production code generation from the modeler's perspective.

You may be apt to believe that creating a modeling language must be a very difficult task. This may certainly be true when building an all-purpose modeling language. How do you create a modeling language if you do not know the type of applications it will model? It is very difficult indeed and you would probably end up with something like… UML, which, as we know is poorly suited for generating full production code.

The language definition task becomes considerably easier when the language needs to work only for one problem domain in one company. You can then focus on a restricted domain—the domain where you have been already working. Narrowing the scope of the language also helps to raise design abstraction, and makes it easier to create code generators to automate development.