所以我假设你的意思是“必须在多个异构系统上运行”。
您将面临指定和实施的问题：
- 业务逻辑
- 用户界面
- 数据模型
- 处理分发的应用程序间通信
如果你关注 Voelter 的论文，你会想要一些东西来描述“架构”，即
这些部分的元素是如何组合成整体的。
如果您的所有平台都不是由一套现成的技术提供服务
（例如，J2EE 或类似的），并且它的生命周期很长，您可能希望将规范分开
这些工件的实现。
(运气好的话，可以选一个普通的
诸如 Java、C# 或 C++ 之类的语言用于业务逻辑，并作为其他 DSL 的编译目标。如果你这样做，当然会很想用那一种语言编写整个事情。如果这样做，您很可能会在下一次技术更新时陷入困境，并且在此应用程序的生命周期中可能会有多次）。
为了将规范和实现分开，您需要一组 DSL 来描述这些规范，并为每个平台提供一组相应的 DSL 编译器，以便所有部分组成
.这意味着您可能无法使用来自不同来源的 DSL；没有理由相信他们生成的结果组成。因此，您可能无法定义这些和实现翻译。这不是一件容易的事。
但是，两者都不是构建一个长期存在的多平台应用程序。
有许多工具可以用来实现这样的 DSL。另一个答案提出了 EBNF，我认为它是描述 DSL 所必需的，以及解析器生成器，我认为这是必要的，但还不够。
更好的实现机制是通用的Program Transformation tools:
所有这三个都可以让您为各种 DSL 定义自己的 EBNF 语法，并构建转换以将它们映射到各种不同的平台。要使用这些，您通常会
需要构成您的多个平台的 target 语言的 EBNF 描述，因为
这些系统通过使用抽象语法树转换方法将 DSL 中的构造转换为目标语言中的构造来工作。其中每一个都有不同程度的现成目标语言描述可用。 （我们努力与 DMS 合作，以确保我们已经很好地涵盖了常用的目标语言）。
这些都不会让你脱离测试。您至少需要在规范级别编写测试，如果没有别的，那么测试的词汇/实现不依赖于特定平台。必须以某种方式编译测试才能运行；如果它们以 DSL 术语编码并且您拥有 DSL 编译器，则可以将它们编译为（多个）实现并运行以验证以 DSL 编码的应用程序。
编辑 10/31/2011：OP 暗示他想要别的东西；在阅读这个问题时，似乎有一些关注于架构规范的 DSL（Voelter 的论文）。我最接近这里的是Module Interconnection Languages (MIL)上的论文调查；其中每一个都是 DSL，需要类似上述开发的东西。 MIL 需要更多；您需要一种方法来执行其规则，否则您在其中编写的任何内容都会被程序员忽略。通过阅读 MIL 和组成软件的各种源代码，您也可以使用各种转换系统来实施强制执行。理想情况下，您应该阅读代码的 MIL 和规范（假设代码生成器生成符合规范的代码）。