Alan Cameron Wills - Domain Specific Languages

Models, domain-specific languages, code generation, ....

Domain specific languages express software refinements

Simon Johnston of IBM has written a note about DSLs (domain specific languages) compared with UML.

One of the excellent points he makes is that very few tools support refinement properly — that is, the layering of a design from abstract requirements to detailed implementation, with the layers connected by abstraction relations. One of the things I did before joining Microsoft was to develop a UML-based method, Catalysis, that was strong on refinement, so I support this wholeheartedly.

But it’s also one of the biggest reasons I like the idea of DSLs. Designing and keeping track of the refinements — especially when one of the layers changes — is tedious and time-consuming, and doesn’t ever get done properly.

With DSLs, there is (in a sense) less need for refinement. Your domain-specific language expresses the concepts of your domain. When I write in SQL, for example, I don’t need to understand how a database works, I just need to understand what a query is. When I design a web page with a WYSIWYG tool, I don’t need to know HTML, or how a web browser works: I just need to know what I want the page to look like.

The implementation of the DSL captures the refinements — that is, the architecture and patterns that are appropriate for this domain. So, yes, the refinements are there; but we’ve separated them out.

So if my next project is to design a big financial trading system, I’ll start by designing a language that is good for expressing financial trading systems and which helps you see immediately the differences between one such system and another, and doesn’t say anything about what they all have in common. Then I’ll set to work to design a platform that implements that language. And the benefit is that the high-level design — about what this particular system is currently required to do — will be decoupled from the implementation of the language, and can be responsive to changes. And my refinement — the mapping of high-level concepts to detailed design — is captured as the design of the language; and I don’t have to update it every time I change the high-level design.

In summary, a DSL represents a class of refinements; so you don’t need to redefine the refinement every time you change the top level.