在本文中，您将发现 MDD 如何支持架构驱动方法来进行开发。

　　MDD 概述

　　在 MDD 中，模型不仅用作框架或蓝图，而且作为通过变换的应用来生成的有效实现所依据的主要工件。在 MDD 中，当开发新的软件组件时，面向应用领域的模型是主要焦点。代码和其他领域工件是利用将来自建模专家和目标领域专家的意见作为输入的转换来生成的。

　　定义架构和架构风格

　　IEEE 将架构定义为：

　　软件系统的架构(在一个特定的时间点)是通过接口，那些由连续的较小组件和接口组成的组件，交互的重要组件进行组织或结构化的。

　　在软件架构的开发方面，我们投入了大量的工作和专家经验。架构反映了有关功能在系统中如何分布，要使用哪些技术，及要采用哪些设计模式的决定。

　　架构包含了一组架构原则和决定。有时候这些架构原则被记录下来，但常常推论的原因却无从得知。在一些情况下，甚至没有对架构原则进行过充分的考虑，这导致了糟糕或不一致的架构。当然，编写架构原则是一个好的主意，但是如果您可以更进一步，并以变更或引入架构原则会实际地改变系统架构的方式获取它们会怎样呢?而且，如果您能将那些同样的原则应用于多个组件、服务和解决方案会怎样呢?这些优势是 MDD 所涉及的。

　　在名为 Convergent Architecture: Building Model-driven J2EE Systems with UML 的书中，Richard Hubert 引入了术语 architectural style(架构风格) 来描述一组可以重复地应用的架构原则。他将架构风格定义为架构家族：

• 　　与公共原则和属性相关
• 　　传达原则和方法，从而最有效地实现设计构想

　　MDD 还将架构风格自动化。在 MDD 中，不仅仅简单地将所实现的解决方案的架构原则、模式，和转换编写为文档。MDD 方法还要求明确地做出架构决策。当获得了新的理解时，MDD 能够更容易地矫正不好的决策。当原则手工地应用于整个系统中时，修改是很困难的。但如果在转换中获取，并被自动地应用，修改转换和再生成是较容易的。在做出最终决策之前，尝试许多其他选择也是花费较少成本的。当通过重复地应用模式和转换以确定最佳匹配来验证解决方案满足非功能需求时，该方法是有价值的。

　　MDD 项目所采用的架构风格是受很多因素影响的，它们包括：

• 　　被开发软件的类别(例如，企业整合、实时的嵌入的、最终用户界面)
• 　　要使用的软件平台的类别(例如，消息传递中间件或基于规则的系统)
• 　　公认的软件开发范例(例如面向服务的或面向方面的)
• 　　软件的领域(例如电信、金融，或零售)
• 　　系统或被开发系统的架构原则
• 　　架构风格的范围(从整个行业的到具体项目的)
• 　　软件开发组织的机构风格(例如，建模惯例)
• 　　解决方案的非功能需求(从服务的质量到表现风格和现有的基础架构)