免责声明：我是业务应用程序的开发人员。以下观点无疑是由我在企业 IT 领域的经验所形成的。我知道软件开发还有其他领域。特别是在工业和/或嵌入式系统开发中，世界可能看起来有所不同。
我认为 MDSD 仍然与代码生成有太多的联系。
仅当您的代码包含大量噪音和/或非常重复时，代码生成才有用。换句话说，当你的代码不能主要关注本质复杂性，而是被偶然复杂性所污染时。
在我看来，当前平台和框架的趋势正是消除偶然的复杂性，让应用程序代码专注于本质的复杂性。
因此，这些新的平台/框架给 MDSD 运动带来了很大的阻碍。
DSL（文本DSL）是另一种趋势，它试图使人们只关注本质的复杂性。虽然 DSL 可以用作代码生成的源，但它们主要与代码生成无关。 DSL（尤其是内部 DSL）基本上让它开放以在运行时解释/执行。 [运行时代码生成介于两者之间]。
因此，即使 DSL 经常与 MDSD 一起提及，我认为它们确实是 MDSD 的替代品。鉴于目前的炒作，他们也削弱了 MDSD 运动的动力。
如果您已经达到了最终消除代码中意外复杂性的目标（我知道这是虚构的），那么您就已经获得了业务问题的文本模型。这不能再简化了！
漂亮的方框和图表不会提供抽象级别的另一种简化或提升！它们可能有利于可视化，但即便如此也是值得怀疑的。图片并不总是掌握复杂性的最佳表示！
此外，MDSD 中涉及的工具的当前状态增加了另一个级别的意外复杂性（想想：同步、差异/合并、重构......），这基本上使简化的最终目标无效！
请看下面的 ActiveRecord 模型，作为我的理论的说明：
class Firm < ActiveRecord::Base
has_many :clients
has_one :account
belongs_to :conglomorate
end
我认为这不能再简化了。此外，任何带有方框和线条的图形表示都不会简化，并且不会提供任何更多的便利（考虑布局、重构、搜索、比较......）。
