模型驱动开发Model Driven Development (MDD) 是一种以模型作为主要工件的高级别抽象的开发方法，模型在工具的支持下，被作为核心资产被转换成代码或者可运行配置。现在软件业存在多种MDD开发方法，本篇将对MDD进行概要介绍。
定义
在过去多年，软件开发面临了多个挑战，新的需求和存在系统不断增长，系统也变得越来越复杂，以至于我们很难及时的构建它们。为了解决这些问题，就出现了很多新的方法，其中最突出的一个就是模型驱动开发。 MDD代表了一套理论和工业化软件开发的方法框架，在软件开发全生命周期中系统的的使用模型作为主要工件，它主要为了解决软件的两个根本危机：复杂性和变更能力 。
使用模型作为文档和规范是有价值的，但是它需要严格的管理方式来确保模型是持续更新的。在实际工作中，我们迫于时间压力经常会出现于实现不一致的模型，这对开发和项目其实是不利的。而MDD的基本思想是让开发中心从编程转移到高级别抽象中去，通过模型转成代码或其他工件来驱动部分或全部的自动化开发。
模型是一种抽象的语言
多种模型
模型是一种建模语言，它需要我们自己根据业务和技术需要去设计它，在架构、分析、设计、实现等不同阶段都会存在多种模型， 如企业架构模型、技术架构模型、领域模型、UI模型、数据库建模、业务规则模型、系统部署模型、测试模型等。
建模的过程是由不同阶段的成员来完成，有些模型之间有引用关系，应用软件通过所有人的建模工作而构建起来。
三个阶段
- 建立模型
- 建模
- 模型转换
模型和建模这两部分内容已经存在很多方法，它们在现在软件开发过程中已经处于重要位置，但是在需要哪些表达模型以及如何使用这些模型存在着差异。传统的模型只是一个设计蓝图，而MDD必须满足额外的要求，这些模型必须是可读的，也就是说必须存在第三个阶段，也就是模型转换：model to model (M2M) 和 model to code (M2C)
优势
- 提高产能：开发快、降低成本、提高质量
- 可维护性：高级别模型与技术分类，技术架构的改变意味着只是模型的一种新的转换
- 一致性：手工编码和架构决策容易出错，MDD可以确保生成的工件是一致的
- 可重用性：模型、转换和架构都是可以重用的，由于架构和技术问题已经被解决，所以开发新功能的风险也低
- 改善涉众沟通：模型忽略系统逻辑行为的底层实现，而直接展现问题域，这样可以保证和涉众使用同一种语言进行沟通
- 改善设计沟通：模型与系统是匹配及时更新的，所以可以通过模型来改善系统设计的讨论和沟通
- 捕获领域知识：可以加强领域专家对系统的直接影响，通过模型还可以帮助组织进行知识管理
- Business-IT对齐：关注问题域，关联技术域，一种业务和IT对齐的方法
- 模型作为一种长期的核心资产：高级别的模型作为核心资产管理起来，只有在业务需求变更时才会进行更改
- 推迟技术决策：应用开发在早期关注业务逻辑问题，对于技术选择可以推迟到后期
- 提供及时的文档：通过模型可以生成很多同步的文档，利于与不同涉众进行交流
经济模型
MDD方法相关
- 特定领域建模 DSM：OpenExpressApp将借鉴此方法
- 面向语言编程 LOP
- 软件工厂 SOftware Factories
- 产生式编程 Generative Programming
- 语言工作平台 Language Workbenches
- 意图软件 Intentional Software
- 模型驱动开发 MDA
一个参考的模型驱动DSL框架
Eclipse Modeling Project
MDE - Model Driven Engineering - reference guide
参考：Model Driven Development – Future or Failure of Software Development
本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/517122，如需转载请自行联系原作者
