我从 1997 年开始使用模型驱动技术和 DSL，我对 MDE 越来越感兴趣。
我可以证明，在某些情况下，达到 10 倍以上的生产力（甚至可能更多；-）是可能的。我已经实现了许多模型驱动的软件工厂，它们能够使用非常简单的模型生成可执行软件，从持久性层到 UI 层，与它们生成的技术文档相关联。
但我不遵循 MDA 标准有几个原因。MDA 承诺以 PIM 模型表达您的软件，并能够自动将其转换为一个或多个技术堆栈 (PSM)。
但 ：
- 谁需要在现实生活中针对多个技术堆栈？谁需要针对一个单一且定义明确的架构？
- MDA 的魔力在于 PIM->PSM 转换，但是以迭代和增量方式进行 model2model 转换很困难：
- model2model 的实现、调试、维护比 model2text 复杂得多。
- 由于几乎不可能生成 100% 的软件，因此必须将细节添加到生成的 PSM 模型中，并在转换后保留转换。这意味着合并操作（3 路，以记住添加的细节）。在处理模型时，对象的合并图比文本合并要复杂得多（效果很好）。
- 你必须处理一个 PSM 模型（也就是说一个看起来非常接近你最终生成的源代码的模型）。这对工具供应商来说很有趣，因为现成的 PSM 配置文件和相关的代码生成器可以与 MDA 工具一起销售和交付。
我提倡 MDE 策略，其中 PIM 是一种 DSL，它讲述您的逻辑架构（独立于任何技术堆栈），并使用自定义和特定代码生成器从该 PIM 生成代码。
优点：
- 您不必处理复杂的技术性 PSM 模型。你有你的代码。
- 使用 DSL 技术，PIM 更有效、更可持续、更具表现力，并且易于由代码和文档生成器解释。模型保持简单和精确。
- 它使您有义务尽早定义您的架构要求和概念（因为它是您的 PIM 元模型），独立于任何技术堆栈。通常，它是关于识别各种类型的数据、服务、ui 组件，以及它们的定义、功能和特性（属性、与其他概念的链接；...）。
- 生成的代码符合您的需求，因为它是自定义的。如果您生成的代码扩展了一些额外的手动维护的框架类，您可以使其更加简单。
- 您以几种正交的方式利用知识：
- 模型利用功能/业务
- 代码生成器利用从逻辑架构组件到特定技术堆栈的技术映射决策。
- PIM DSL 将您的逻辑架构的定义大写
- 使用面向逻辑架构的 PIM，可以生成所有技术代码和其他非代码文件（配置、属性等）。开发人员可以专注于模型无法完全表达的业务功能的实现，通常不必再处理技术堆栈。
- 合并操作都是关于平面源代码文件的，这很好用。
- 如果您针对多个技术堆栈，您仍然可以定义多个代码生成器。
缺点：
- 您必须实现和维护自己的特定代码和文档生成器
- 一般来说，要充分利用 DSL 方法，您必须投资特定工具（模型验证、特定向导、对话框、菜单、导入/导出......）。
- 在更新/改进您的 DSL 时，您有时需要迁移您的模型。通常这可以通过一些一次性迁移代码来完成，或者手动完成（取决于影响）。
- 所有这些缺点都需要具有模型驱动技能的特定开发人员团队
这种特殊的方法可以在具有 UML 配置文件或特定模型编辑器（文本或图形）的可扩展 UML 建模器之上实现。
MDA和MDE之间的巨大区别可以概括为：
- MDA 是一组通用工具和语言，为每个人的需要提供现成的 md 配置文件和工具。这对于工具供应商来说是完美的，但我怀疑每个人的需求和背景都不同。
- 使用 MDE + 特定的 DSL 和工具，您需要一些辅助的、熟练的模型驱动开发人员来维护您的自定义软件工厂（建模器、建模器扩展、生成器......），但您可以随时随地利用并管理非常简单-精确-可持续的模型。
这两种方法之间存在某种利益冲突。一个提倡重用现成的预资本化模型驱动组件，而在另一个方面，您可以通过定义 DSL 和相关工具来实现自己的资本化。