Johan den Haan agreed in his comment with most of my thoughts on Microsoft's odd new DSLs + UML approach, and wrote an interesting article of his own on the topic. I agree with him that there are situations where framework-based DSLs make sense, and that one of the major criteria in such situations is the cost-benefit analysis. Given a choice of no MDD, MDD with your own DSL, and MDD with an existing third party DSL, just look at how much it costs to develop your apps in each case, and how much to develop or buy the DSL and its tooling.

If you decide to create your own DSL, there's normally no question: it should be made for your problem domain, not your solution domain. That gives higher productivity, more flexibility and more future-proofing (you can change solution domain by one person changing the generator, no need to update the models or language).

The possible exception is when, like Johan, you decide you want to sell your DSL as a tool, rather than use it to make your own apps. In that case you need to factor expected selling price against expected market size and the work required to create the solution:

• Expected selling price is largely a measure of the productivity increase. It is thus higher for problem-domain specific DSLs, and increases the more specific the DSL is.
• Expected market size is greater the less specific the DSL is. As many development organizations see themselves as "J2EE developers" rather than "webstore developers", it may be easier to market solution-domain specific DSLs. Similarly if you already have a captive market, as Microsoft does with Visual Studio users, it makes sense to sell solution-domain specific DSLs.
• The work needed to support an extra solution domain is mostly the cost of becoming proficient in the new framework or language. Since we're assuming the solution domain language or framework isn't perfect, and is probably a pain to use (increasing the marketability of the DSL), that's probably quite a large amount of work. Also, developers will judge a DSL by the quality and familiarity of the code it outputs. This means you have to reach a good standard of proficiency in that solution domain, and also offer significant tailorability in the code that will be output, so you can suit a larger number of potential customers.

As you can see, the factors and their weights are very different if you want to sell your DSL rather than use it yourself. When selling, many of the benefits of DSM are reduced: the broader DSL leads to lower productivity for your customers, and the broader solution domain support leads to higher costs for you in terms of learning and generator development. Building a DSL for your own use is a lot easier and cheaper, and gives greater benefits.