我们正在评估我们在流程中使用外部DSL的程度，以描述，建模和生成多平台应用程序。我个人没有看到很多应用程序来描述Enterprise-Domain，因为在我的情况下，大多数应用程序都很简单。而密集的测试驱动开发似乎更适合剩下的任务。
在技术方面还有其他挑战，我想用坚实的策略来应对。由于有可能拥有众多系统，我想尽可能好地描述接口。
我发现一些ORM-Frameworks有一些代码/ shema转换器来自一些meta lnaguages（Doctrine看起来不错），还有一些文章来自Markus Voelter（特别是'Architecture as a Language'）。
你知道其他任何有趣的，甚至是矛盾的例子吗？
答案 0 :(得分：7)
因此，通过Multiplatform，我认为你的意思是＆＃34;必须在多个异构系统上运行＆＃34;。
您将面临指定和实施的问题：
如果您关注Voelter的论文，您将需要一些东西来描述＆＃34;架构＆＃34;，即 如何组成每个部分的元素来实现整体。
如果您的所有平台都不是由一套现成的技术提供服务的话 （例如，J2EE或其他一些），并且它具有很长的生命周期，您可能希望将规范分开 这些工件的实现。
（如果你很幸运，你可以选择一个普通的 用于业务逻辑的Java，C＃或C ++等语言，以及其他DSL的编译目标。如果你这样做，当然诱惑就是用一种语言来编码整个事物;如果你这样做，你可能会在下一次技术更新时遇到困难，并且在这个应用程序的整个生命周期中可能会有几个。）
为了使规范和实现保持独立，您需要一组DSL来描述这些规范，并为每个平台创建一组相应的DSL编译器，以便所有部分组成 。这意味着您可能无法从不同来源获取DSL;我们没有理由相信他们产生的结果。因此，您很可能无法定义这些和实现翻译。这不是一件容易的事。 但是，它们也没有构建一个长期存在的多平台应用程序。
有许多工具可用于实施此类DSL。另一个答案提出了EBNF，我认为需要它来描述DSL和解析器生成器，我认为这是必要的但是不够充分。
更好的实施机制是通用的Program Transformation tools：
所有这三个都可以让您为各种DSL定义自己的EBNF语法，并构建转换以将它们映射到各种多个平台。要使用这些，您通常会这样做 需要构成多个平台的目标 langauges的EBNF描述，因为 这些系统通过使用abstract-syntax-tree转换方法将DSL中的构造转换为目标语言中的构造。这些中的每一个都具有可用的现成目标语言描述的不同程度。 （我们努力与DMS合作，以确保我们已经很好地涵盖了常用的目标语言。）
这些都不会让你退出测试。您至少需要在规范级别编写测试，如果没有别的，那么测试的词汇表/实现不依赖于特定平台。测试必须以某种方式编译下来运行;如果它们以DSL术语编码并且您有DSL编译器，则可以将它们编译为（多个）实现并运行以验证在DSL中编码的应用程序。
编辑10/31/2011：OP提示他想要别的东西;在阅读这个问题时，似乎有一些关注用于架构规范的DSL（Voelter的论文）。我能来的最近的是对Module Interconnection Languages (MIL)的论文的调查;每个都是DSL，需要像上面的开发。 MIL需要更多;你需要一种方法强制执行它的规则或者你写的任何东西都会被程序员忽略。通过阅读MIL和构成软件的各种源代码，您还可以使用各种转换系统来实施强制执行。理想情况下，您需要阅读代码的MIL和规范（假设代码生成器生成符合规范的代码）。
答案 1 :(得分：2)