I’ve been keeping a sceptical eye on Software Factories and Model Driven Architecture (MDA) for some time so I was very interested to see a Domain Specific Language (DSL) API spring up in the latest drop of Visual Studio. I thought I’d better do some reading around the area to try and understand its goals. During my "travels" around the web I came across the following blog, Jack Greenfield’s Blog. Amongst other things it talks about an on going debate about using UML for MDA (and for Software Factories in general) vs. DSL. Now all the arguments for and against each one are all very interesting and exactly the sort of thing to get real-ale drinking software architectures in a bother, however for me there is one clear advantage for DSL…the average user. I don’t think I’d be burnt at the stake for suggesting that as good as UML is, the majority of people successfully cherry pick UML in order to describe/document their solution, very few would take it through every stage. Again I don’t really want to get into a debate about why people don’t use UML I just want to state that, rightly or wrongly, people don’t believe it is some kind of silver bullet/fits-all language. This brings me to my point (hurray), so far I’ve been talking about people in the software business what hope have we in convincing Joe public to use UML? As much as we like to make our solutions generic it often becomes more complicated for the average user. Did the average user welcome the fact that they could use VBA in Word and Excel? Sure the developers (and hackers) did but did the average user? I’d suggest not. What the user wants is something that talks in the language they understand. So for Word they’d probably want something that talks about text changes, font formatting, picture adjustments, spelling, etc. For Excel formulas, statistics, graphs, etc. Now sure there is some common ground that could be exploited but basically the domains are different. So assuming that I’ve established that the user wants domain specific tools how to best address that? This is where the arguments of DSL vs. UML step in. But wait, if we can’t convince the software development community about UML how on Earth are we going to convince Joe public, surely it will be better to provide specialised DSL for the users problem domain? "But they’d have to learn a new tool/language for every one", I hear you cry. True, partly. This brings me back the cherry picking of UML. Personally I feel UML is too verbose and clumsy to be used "correctly", but what it is great at is conveying ideas and requirements without necessarily concretely specifying them. E.g. I can draw an interaction diagram describing how to spell check and save a Word document, but I wouldn’t feel it necessary to write out a full class specification for a Word document so I could include it in the interaction. I realise this might shock the purists but I’d argue that the real goal of UML is to successfully convey the requirements and to describe the solution. I believe it is successful at this because the concepts of shapes and flow are pretty easy to understand even without formal training. Therefore I believe that providing you implement your DSL using fairly simple concepts but still talk in the context of the domain you can take the reusable parts of UML and still provide the average user with a toolset they can understand.