15种你应该使用模型驱动开发MDD的理由

使用面向对象思维的MDD/DDD已经是一种主流发展方向，DSL属于MDD一个更高级发展，企业架构网站昨天推出一篇15 reasons why you should start using Model Driven Development，有15种理由，应该足够说服任何人了。

1. MDD is faster MDD很快（真正快速开发）
在MDD应用模型中能够指定一个比传统的编程语言更高的抽象层次。该模型能够自动转化为可立即运行工作的应用程序（通过UML工具），生成可解释/执行模型代码。模型中的每个元素代表了多行代码，这样使得模型在一个更高的抽象层次比相应的代码要精简得多，更能大道至简。

2.MDD is more cost-effective MDD更具有成本优势
因为MDD快速开发所以比较快地推向市场，MDD意味更少的人员 专家，更高的质量，成本只是你学习MDD的成本以及工具采购，使用MDD拓展和维护应用程序的做法也更符合成本效益。通过更高级别模型阅读，比较容易理解应用程序。

3. MDD leads to increased quality MDD引导质量提高
因为软件架构是在一个更高模型级别定义，然后通过引擎或框架转换成代码，这样我们能够让我们最优秀的人员从事引擎和框架的开发，进而提高平台的质量。 我们在项目中学习到的最佳实践模式可以被导引到引擎或框架代码产生器中，这样将被重用到所有使用MDD的项目中。

4. MDD is less error-proneMDD很少出错
测试会浪费很多时间，因为MDD可以确保代码的质量，这样让你可以专注于测试应用程序的特点功能即验收测试上，不必关注通用的一些测试项目，如基础设施相关的技术问题或安全漏洞。

5. MDD leads to meaningful validationMDD引导有意义的校验
业务验证都已经在更高级别的模型中完成，编程工具只能帮助你验证代码语言的错误，不能验证业务上的错误。

使用DSL能够在设计时候就执行一下，这样，错误信息也是 domain-specific级别的，可见Static Verification: An External DSL Advantage一文。

6. MDD results in software being less sensitive for changes in personnelMDD可以不在乎人事变动
不需要特别的技术高手或架构师就能够建立软件，节约人力成本。此外，如果有人加入一个项目，比较容易理解高层次的软件应用模型，这比试图通过阅读理解源代码要轻松多(banq个人体会：本人曾经只用两三个月就理解了一个中型NGOSS级别的BOSS系统(通过together逆向工程模型化)，当然也主要因为原系统基于Hibernate的模型对象化，如果是纯粹基于SQL就没有这么幸运了)。

7.MDD empowers domain expertsMDD授权领域专家
业务领域专家能够注重建模，而技术专家可以专注于建立一个MDD需要的框架或DSL等工具。一个软件系统不再只是程序编制就可以了，领域专家可以通过符号（如文字，图形，表格）等直接表达他们对业务领域的深入理解 。

8. MDD let advanced programmers focus on the hard stuff MDD能够让高级程序员专攻难关
在MDD中，高级程序员的重复性工作要少得多，他们可以专注于他们工作的创造性方面。他们可以集中精力建设MDD的工具。他们还可以指导初级开发或领域的专家，也可以申请领取困难攻关，领域专家可以专注例如模型的图形用户界面，流程和业务规则。而应用程序的集成部分（使用webservices，API调用，数据库集成等）对于领域专家来说，存在太大困难，可以由高级程序员来完成。

9. MDD bridges the gap between business and IT MDD在业务和IT之间架设了桥梁
领域专家（或系统分析师）可以直接参与业务发展进程（见第7点）。
技术专家（软件应用）可以在一个更高的层次定义尽可能和领域概念的定义声明有关模型。
通过在模型和模型实现之间定义一个重要的转换机制，就可以在业务和IT技术之间建立一个桥梁，比如使用一个基于model-driven SOA的框架。

10. MDD results in software being less sensitive for changes in business requirements MDD可以减少业务需求带来改变的影响面
对软件开发的问题之一是业务需求经常变化速度超过了软件系统支持改变，这对于企业是一个重点战略问题：能够保持足够长的时间调整其核心业务与IT流程。
MDD使软件开发更快（见第1点），它也导致更容易改变应用（因为第2点和6）。如果在业务需求和软件之间的存在一个联系，那么应用程序甚至有可能自动适应部分模型的变化（见第9点）

11. MDD results in software being less sensitive for changes in technology MDD导致技术对变化不是太敏感
技术变化很快， Java EE, SOA / SOBA, webservices, REST, SCA, OSGi等等，甚至迁移到云计算环境，当您希望您的应用程序迁移到其他技术时，MDD可以确保你不必改变你的应用模型，。唯一需要改变的代码生成器（或DSL解释器）。改变后的代码生成器（或添加额外的代码生成选项）可以帮助所有的应用程序模型直接转换成基于新技术架构的代码。

12. MDD really enforces architecture MDD增强架构
当使用MDD开发软件应用程序，保证符合选定架构。你可以真正实现架构标准化， 构建架构原则Constructional architecture principles能够知道设计构建，并且能够反映在代码生成器或解释器中。

13. MDD captures domain knowledge MDD可以截获领域知识
关于MDD的优点是，你不是只创建软件，但你也捕捉正式高层次的领域知识模型。在大多数情况下这方面的知识是不明确，见文章基于DDD的DSL

14. MDD provides up-to-date documentation MDD提供最新的文档
当使用MDD是，您不会遭遇不完整或过时的文件，因为该模型使用正确的抽象，可以让领域专家和客户都能看懂。

15. MDD enables to focus on business problems instead of technology MDD能够关注业务而不是技术
停止讨论使用WS-* 或者 REST，MDD能够让你专注于业务问题如何解决，而不是着眼于如何解决这些问题的技术支撑。