二、模型驱动将成为救命稻草
今天的企业需要一个新的方法来模型化对象，其中一个原因是需要更短的开发周期以及最小化开发风险。对象管理组织(OMG)只在2001年介绍了一个：模型驱动构架。这个MDA范例进化了模型，并可以应付复杂度不断增加的企业系统设计。MDA是一组通过继承XML实现的相关技术，这些技术可以将模型转化为文本，以及模型和模型之间的转换，这么做可以确保模型能以更高的效率和更灵活的应变能力来开发系统。
今天的企业需要一个新的方法来模型化对象，其中一个原因是需要更短的开发周期以及最小化开发风险。对象管理组织(OMG)只在2001年介绍了一个：模型驱动构架。这个MDA范例进化了模型，并可以应付复杂度不断增加的企业系统设计。MDA是一组通过继承XML实现的相关技术，这些技术可以将模型转化为文本，以及模型和模型之间的转换，这么做可以确保模型能以更高的效率和更灵活的应变能力来开发系统。
MDA使用的理念是构架师可以画出所有企业商业领域的内核对象的草图模型。这些对象仅仅是商业对象，并没有将来打算建立它们所使用的技术。一但这些构架师对自己画的模型草图可以准确的描述真实世界的商业模型时，构架师将使用一个基于MDA的模型工具来进行模式转换。
一但开始转换，这些工具将扫描每一个由构架师画的草图来发现商业模型。使用被封装在转换模式中的条件逻辑，可以获得基于所扫描到的对象的确定的动作。转换的输出结果就是可执行的代码，这些代码可以被编译，发布和运行。在适当的地方或功能使用这项技术，可以使企业应用开发人员更轻松地编写满足用户需求的商业特性。
三、MDA是否会真的被广泛应用
今天，MDA阵营里分为了两派，也就是它的支持者和反对者，但这两派都承认MDA的发展和被采用的速度非常缓慢。Forrester在2007年4月的调研报告“模型驱动开始的现状”中提到MDA将由于更广泛的原因而影响它的推广和普及，有很多客户和开发人员经常抱怨MDA有以下缺陷：
1. MDA非常复杂和学术化
2. MDA很严格
3. MDA仅仅是代码生成器
但我认为MDA的使用并不需要流于形式。它非常具有可实践性和弹性。事实上，支持MDA的工具已经得到了非常大的发展。我建议这些对MDA有敌意的人看看以下几点意见：
1. MDA不仅仅是支持UML的特定领域语言（DSLs）的翻版，这种语言能以可视化的方式来为我们画UML图，这个工具也可以自动写代码。然而，UML通常被认为是非常复杂和局限性，然而，作为另一种选择，自由的流模型经常不支持本质的上下文和生成UML的技术。和UML相比较，多种目的的模型语言，DSL允许我们建立描述应用程序构架和通过自己的商业模型来进行商业处理的符号，它们改善了横跨整个商业模型的可用性和应用能力。
但我认为MDA的使用并不需要流于形式。它非常具有可实践性和弹性。事实上，支持MDA的工具已经得到了非常大的发展。我建议这些对MDA有敌意的人看看以下几点意见：
1. MDA不仅仅是支持UML的特定领域语言（DSLs）的翻版，这种语言能以可视化的方式来为我们画UML图，这个工具也可以自动写代码。然而，UML通常被认为是非常复杂和局限性，然而，作为另一种选择，自由的流模型经常不支持本质的上下文和生成UML的技术。和UML相比较，多种目的的模型语言，DSL允许我们建立描述应用程序构架和通过自己的商业模型来进行商业处理的符号，它们改善了横跨整个商业模型的可用性和应用能力。
2. 所有权模式和转换内部锁已以是过去的东西了。在现在的MDA内核中已经是转换模式了，这是一种可以使代码独立于商业模型之外的指令集合。然而MDA用户一但由于客户的需求变化而陷入危机时，就可以使用一种叫查询、察看和转换（QVT）的标准语言来灵活地使MDA转换为UML、商业处理模型符号（BPMN）,数据模型以及可定制的模型类型。
3. 模型到文本的转换可以使我们节省很多时间。我们使用MDA是因为我们不用想着如何来产生代码吗？还是我们需要开发其他什么东西（如文档、发布描述文件、测试等）？事实上MDA的模型到文本的转换可以自动的产生从已存在的设计模型中能找到的所有的东西。这可以使开发人员减轻压力，转而从事更为重要的工作。
四、MDA价值的另类看法
当应用程序和商业处理的复杂度继续升级时，高效的模型解决方案的重要性更加显得突出。模型解决方案可以确保一个足以影响整个构架设计的方案以一种可视化的方式解决。模型提供的功能不仅仅是商业处理、应用程序以及企业构架，还有很多数据结构。他们可以使多个项目团队之间互相沟通，以及可以确保更完美的构架设计和长期的可维护性。更在进化的支持MDA的工具的下一步发展将是成为一种高效的模型系统。因此，所有的企业应用团队应该重新审视这种蓬勃发展的模型技术。
