第 1 部分: 实现模型驱动开发，增加您的 IT 系统的业务价值

发现使用 IBM Rational 软件中的建模工具的优点

您是一位试图增加 IT 系统业务价值的领头架构师或项目经理吗？如果您是，本文可以为您提供帮助。本文解释了影响现代 IT 开发的业务推动力，并且向您介绍了模型驱动开发（model-driven development，MDD）。MDD 是主流软件开发实践的提高，并且让您的 IT 系统能够对业务推动力更加敏感。了解 MDD 方法以及您如何可以将其应用于实现业务价值最大化，并且减少解决方案开发的成本。利用 MDD，通过利用转换和重复性的消除将实现模式自动化，并将低层次的开发工作自动化，您可以提高解决方案的一致性和质量。

了解您目前的业务环境

IT 开发不会孤立出现。IT 的目的是简化业务运作，这意味着业务环境的需求推动着我们开发 IT 的方法。表 1展示了一些当前的业务推动力。

表 1. 当前的业务推动力

了解软件开发的模型驱动方法

模型驱动开发（Model-driven development，MDD）是软件开发的一种样式，其中主要的软件工件是模型，根据最佳实践，可以从这些模型生成代码和其他工件。模型是从特定角度对系统进行的描述，它省略了相关的细节，因此可以更清楚地看到感兴趣的特性。例如，结构工程师会创建适合于确定建筑物承载特性的模型。

在 MDD 中，我们引入了附加的标准，即模型必须是计算机可读的。例如，我们必须能够以自动化的方式估计模型的内容。模型的计算机可读性是它能够生成工件的必要条件。白板上的图也许满足作为模型的其他标准。然而，直到我们以计算机可读的方式获取它时，才能够在 MDD 工具系列中使用它。

软件模型一般用统一建模语言（Unified Modeling Language，UML）表示。UML 是用于说明、可视化，并文档化软件系统的语言。它为软件模型提供了可视化的表示和基础的语义。UML 还拥有用来确保自动化的标准化的计算机可读的序列化格式。

软件模型隐藏了技术实现的细节，因此，我们可以利用来自应用领域中的概念来设计系统。应用程序一般是利用 UML 建模工具，例如 IBM Rational? Software Architect，并使用与应用领域相关的概念进行设计的。例如，当我们工作于企业集成领域中时，我们会利用消息、代理和适配器这样的概念为应用程序设计建模。随后，我们可以精练该软件模型，并且为其组件设计详细内容。

作为示意图和蓝图的模型

利用模型来设计软件是一个公认的实践（尽管的确不普遍）。目前，模型大多用于通俗地传达系统某个方面的示意图，或用于描述您手动实现的详细设计的蓝图。

将模型作为文档和规范是有价值的，但是这需要严格的规程来确保模型与实现进度保持一致。通常，时间约束意思是在没有首先变更模型的情况下，对实现进行了更新。不准确的模型比没有模型更有害。

在本文中，我们用术语 MDD 来表示由模型自动生成工件的方法。

利用准确的模型进行自动生成

在 MDD 中，模型不仅用作示意图或蓝图，它们还作为通过转换的应用，生成有效实现的主要工件。在 MDD 中，当开发新的软件组件时，首要的焦点是面向应用领域的模型。代码和其他目标领域的工件是利用由建模专家和目标领域专家的参与所设计出的转换，来生成的。

MDD 能够极大地减少解决方案开发的成本，并且提高解决方案的一致性和质量。这些好处是通过自动化带有转换的实现模式来形成的，它消除了重复的低层次开发工作。在构建解决方案工件时，与其重复地手动应用技术经验，不如将这些经验技巧直接编入转换中，并且还带来一致性和可维护性的优势。修改了的转换可以快速地重复应用，用于生成反应出对实现架构做出的变更的解决方案工件。

MDD 将应用程序开发的重点从平台上移开，让具有应用程序开发经验的开发人员，在不用关注具有平台经验的开发人员的领域中的平台级概念的情况下，设计应用程序。平台经验直接在转换中获取，而不是编制为项目指导，或者更糟的是，在项目进行的过程中重新去多次发现。同样，关于实现架构的决策也直接编入转换中，而不是编制为架构决策的文档。

根据情况的不同，合适的成品转换会用于直接的使用，或者作为扩展的基础。另外，您可以为项目构建定制的转换。

不仅是代码

虽然代码和其他平台工件的生成是 MDD 的重要部分，但是 MDD 样式的自动化有更深的意义。软件开发项目需要生成许多非代码的工件，其中一些完全或部分地来源于模型。以下的列表提供了一些由模型生成的通用工件实例，但您可以考虑其他的。

文档

在遵照正式的开发方法的组织中，生成文档用去了大量的开发精力。将文档与实现保持一致出了名的困难。当使用 MDD 时，文档由模型生成，它们确保了一致性，并且使开发人员日常处理的模型中的信息可用，比在很难将信息定位的文档中要好。工具，例如 Rational SoDA 和 Rational Software Architect Report Generator （参见 参考资料）可以生成文档，或者文档由转换来生成。

测试工件

由软件模型中所包含的信息生成基本的测试，例如利用 JUnit，是有可能的。如果执行了额外的具体到测试的建模（例如，利用 UML Profile for Testing），那么就可以生成完整的测试实现。基于模型的测试是关于由模型生成测试的规程。

构建及部署脚本

基础结构架构师利用他们的经验可以创建生成构建及部署脚本的转换。

其他模型

一个系统中会涉及到许多不同抽象层次上（分析、设计、实现）的相互依赖的模型，它们代表系统的不同部分（UI、数据库、业务逻辑、系统管理）、不同的关注点（安全性、性能，及可靠性），或者不同的任务（测试、部署建模）。在许多情况下，由一个模型部分地生成另一个模型是有可能的，例如，从分析模型到设计模型，或者从应用模型到测试模型。

模式应用

模式获取最佳实践解决方案来重现问题。模式指定模型元素的特性，以及那些元素之间的关系。您可以将模式自动化，以便创建新的元素，以及修改现有的元素来遵照该模式，然后将模式应用于模型中。

在本文中，我们介绍了所有这些技术，除此之外还有利用 MDD 进行的代码生成。

为 MDD 项目估计任务

MDD 对我们构建业务应用软件的方式有着深远的影响。它获得了顶级技术人员的经验及决策，通过为项目的需求所定制的工具使余下的团队可以获得这些经验和决策。由于大量的低层次编码工作已经自动化了，所以开发的成本，以及测试业务软件的成本极大地减少了。错误的数量减少了，并且在工作完成的方式上增加了一致性。

然而，MDD 确实创建了项目的不同一面，需要管理一个项目中的另一个项目。内部工程包含了 MDD 工具的开发，这些工具可以供开发团队在外部项目中构建业务应用程序时使用。一般来说，开始要将一个业务应用程序确定为利用 MDD 工具构建的，着重于需求，并且可以对该方法进行一些调整的第一个项目。一旦开始开发了，就可以将 MDD 工具用于构建许多业务应用程序了。

对于两个项目，谨慎地组织和计划是非常重要的，特别是在一开始的时候。在与开发项目相关的平常问题之上，存在着管理额外的内部依赖集的需求。MDD 工具需求必须在应用程序开发人员需要它们之前进行确认和开发。两个项目的任务流要互相联结的，这样可以确保由 MDD 工具项目而来的交付产品是及时的。

图 1 展示了 MDD 项目中的任务流。阴影的任务可能在传统项目中执行。白色的任务是为具体项目构建 MDD 工件的附加任务。

图 1. 开发 MDD 工件的步骤

您可以在业务应用程序开发之前开发所有的工具，或者利用更加迭代的“准时制（just-in-time）”方法。不论采用哪种方法，重要的是，在业务应用程序项目开放过程中，允许有额外的时间来开发被确定为第一次使用的工具的增强。

任务

开发 MDD 工具的最初任务出现在所有的传统开发方法中。您的解决方案架构师执行了这些任务，并且定义了业务应用程序的高层结构。

创建解决方案架构

定义业务应用程序的概念结构。这可以表示为，在构建业务应用程序时，开发人员将要采用的许多架构风格。

定义运行时环境

定义业务应用程序运行所处的运行时环境。这包含所有的测试环境，其中包括单元测试和最终的产品环境。

一旦开始的两个任务完成了，解决方案架构师就会很好地了解了为业务应用程序开发什么需求了。到此，具体到 MDD 的任务可以开始了：

确定通用的模式和标准

解决方案架构师确定出在业务应用程序中的重复模式。这些模式的经常出现，是由于架构风格的一致使用，或者由于运行时平台的需求。通用的模式可以利用对组织的开发过程来说标准的方式进行描述。

确定用于复用的现有 MDD 资产

解决方案架构师比较他们用现有 MDD 资产确定出的通用模式，对他们的架构做出任何必要的小调整，从而使用已经可用的内容。现有的 MDD 资产可以来自先前的 MDD 项目，或者来自标准的工具和包。

定义设计模型

解决方案架构师定义开发人员在开发业务应用程序时必须依据的建模规则。一般开始会选择 UML，且解决方案架构师会更精确地定义如何利用 UML 来获取设计。解决方案架构师需要了解不同类型的 UML 图（例如，类图、协作图、活动图）以及什么时候适合使用哪一种。

确定独立于运行时的组件模型

该任务创建了一个 UML 模型的定义，该模型以独立于运行时的方式为业务应用程序指定了组件。该任务可以由解决方案架构师执行，或者由了解所有运行时环境的有经验的应用程序开发人员执行。

生成示例工件

应用程序设计人员为典型的场景手动编制结果的业务应用程序工件。这些示例工件是作为 MDD 模板和转换的蓝图的。该任务应该由您的最佳应用程序设计人员执行。

确定工具系列

该任务确定了开发项目所需的 MDD 工具。该任务是由掌握 MDD 工具开发的人来完成的。一旦完成了该任务，您就可以创建构建 MDD 工具所需的工作的详细计划了。

接下来的五个任务构建了 MDD 工具：

从示例工件中抽取模板

MDD 工具开发人员审阅示例工件，并且将它们用作为每个待生成的工件开发模板的基础。模板包含了对于已生成工件的每个实例都相同的代码。MDD 工具开发人员需要掌握已生成工件的语言和格式方面的技能。它还包含转换所使用的，根据模型的内容插入工件的具体部分时所需的标志。

设计、代码、测试转换及模式

该任务需要 Java 程序设计能力。对于每个转换或模式，MDD 工具开发人员需要书写阅读 UML2 模型的 Java 代码，然后更新模型，或者对模板进行适当填充，生成新的工件。

包装 MDD 工具

MDD 工具必须打包成可以安装到每个人或您的应用程序开发人员的工作台中的形式。这里有一些选择：

根据打包的指导，将所有的文件放入 zip 文件中

使用标准的 Eclipse 插件管理

使用可复用的资产（reusable asset，RAS）存储库

提供完整的下载 Web 站点

该选择依赖于可能安装 MDD 工具的人数。一种合理的方法是着重于支持您最初的应用程序开发人员，然后当更多人开始使用它时，按照需要升级打包机制。

为应用程序开发人员生成文档及培训资料

解决方案架构师或技术作者介绍了应用程序开发人员如何构建模型，并且选择恰当的转换来生成正确的工件。

利用关键的场景来验证工具系列

这个最后的 MDD 工具开发任务是一个测试角色。MDD 工具建模并生成每个运行时平台所需的所有工件，来支持一些关键的场景。

现在已经准备好 MDD 工具让应用程序开发人员开始使用了：

培训应用程序开发人员使用 MDD 工具

在使用 MDD 工具之前，告诉应用程序开发人员新的开发过程是如何工作的。他们需要了解什么时候以及如何使用 MDD 工具，并且还要知道这些工具如何配合他们的传统工具，例如配置管理。

开发业务应用程序

到此，应用程序开发人员使用 MDD 工具来构建业务应用程序。

MDD 工具系列

图 2 中的流展示了开发人员如何能够利用 MDD 工具开发部分业务应用程序。在此实例中，开发人员审阅了业务问题，并且选择了设计模式。该模式部分地填充了设计模型，而开发人员填写他们正在构建的具体业务功能的细节。此后，开发过程就完全自动化了。开发人员选择一项来生成工件，这些工件被打包并放入构建区。然后开发人员可以选择更多选项，为个别的运行时平台生成附加的工件。

图 2. MDD 工具链

好处

MDD 拥有极大地提高当前主流软件开发实践的潜能。表 2 展示了 MDD 方法的优点。

表 2. MDD 好处

第 2 部分: 结合模式与建模以实现架构驱动开发

明确地捕获您的架构决策

利用模式和模型驱动开发（model-driven development，MDD）可以进行架构驱动开发。这种开发类型可以使我们明确地获得架构决策，并且在系统中对架构决策自动化编码。通过使用模式及 MDD，您可以减少工作中的复杂性，并且进行按需设计及开发。阅读本文以了解更多关于这些问题的信息，这些内容是建立在对本文的同系列文章“实现模型驱动开发，增加您的 IT 系统的业务价值”的讨论之上的。

引言

在同系列的文章，“实现模型驱动开发，增加您的 IT 系统的业务价值”中，您了解了模型驱动开发（model-driven development，MDD）如何交付价值。在本文中，您将发现 MDD 如何支持架构驱动方法来进行开发。

MDD 概述

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

定义架构和架构风格

IEEE 将架构定义为：

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

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

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

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

他将架构风格定义为架构家族：

1.与公共原则和属性相关

2.传达原则和方法，从而最有效地实现设计构想

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

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

被开发软件的类别（例如，企业整合、实时的嵌入的、最终用户界面）

要使用的软件平台的类别（例如，消息传递中间件或基于规则的系统）

公认的软件开发范例（例如面向服务的或面向方面的）

软件的领域（例如电信、金融，或零售）

系统或被开发系统的架构原则

架构风格的范围（从整个行业的到具体项目的）

软件开发组织的机构风格（例如，建模惯例）

解决方案的非功能需求（从服务的质量到表现风格和现有的基础架构）

获取专家经验

许多 IT 项目都缺乏能够做出架构决策的有技能的专家。这常常导致对关键角色的过渡依赖，缺少了他们将会使项目面临巨大困难。

MDD 的一个关键的方面是专家经验的获取。与其每次需要专家在现场做出最佳实践的决策，到不如在自动的模式和转换中获取他们的专家经验，这样您可以再次运用这些经验。该方法让不具有专家知识的开发人员能够构建成熟的系统。

为了构建 MDD 框架，您需要获取两个主要类型的专家经验：逻辑的（功能的）架构经验和技术的架构经验。逻辑和技术的架构经验都是整个架构风格的一部分。

逻辑的架构经验

解决方案的逻辑架构涉及必须表现出来的功能，而不是利用特定技术实现功能的方式。当使用 MDD 方法时，目标是在逻辑层建模，并且生成实现工件。

在 MDD 中，您定义出逻辑架构风格并且开发了支持该风格的统一建模语言（Unified Modeling Language，UML）概要文件、模式和建模惯例。与定义逻辑架构相关的许多专家经验是在 MDD 框架中获取的，并且在每次开发新的应用程序时应用它们。新应用程序的设计师能够更多地关注问题领域，并且在应用程序间通用的软件架构的一些方面上少投入精力。

技术的架构经验

现代的中间件平台为了支持那些构建在其上的各种应用程序提供了丰富的特性。然而，单个的项目经常使用那些功能的子集，并且它们以专门的方式来使用这些子集。

一个特定的项目（或计划）利用其所选择的中间件平台的方式确定了技术架构。在最佳实践文档中可以获得技术架构，或者可以将技术架构从开发人员传递给其他开发人员。实际上，当处于手工过程中时，很难确保技术架构被一致地应用。

MDD 向您提供了直接实现技术架构的机会。与其在文档中记录，例如，“对所有公共方法的入口和出口都将利用 log4j 来记录”，到不如您实现一个转换来根据该规则生成日志代码。 MDD 方法的一点好处是让您集中在项目较早时期，并且更彻底地考虑技术架构。如果您一开始就了解到这点，并且分配了充足的时间来定义技术架构，那么这将会带来实在的收益，并且在项目的后期节省您很多时间。

了解模式

在 MDD 中，您利用具体领域的概念来建模。例如，在企业整合领域中，您可能会用到消息、代理和适配器。应用领域的词汇中还常常包含模式。在企业整合领域中，您可以保证交付和发布订阅模式。这些模式不是单个的元素，而是引入元素和对其行为的约束之间的关系。

（建筑）架构师 Christopher Alexander 在其著名的 Timeless Way of Building 中引入了模式语言的概念。他的想法，模式作为一般设计问题的最佳实践方法，已经得到软件团体的广泛采纳。他引入了模式语言的概念，他将其定义为可以一起为特定环境或问题领域中的设计提供词汇的一组相关的模式。

在后继卷，A Pattern Language 中，Alexander 介绍了拥有面向城镇设计（目标为计划者）和建筑物（目标为架构师）的子语言，以及面向构建（目标为建筑者）的子语言的具体模式语言。

Alexander 的模式实例是：

1.城镇模式

环形路、夜生活和连排房

2.建筑物模式

屋顶花园、室内日照，和避暑别墅

3.构建模式

好材料、支柱连接，及半英寸的装饰

每个模式都包含它所适用的环境的信息，以及它与其他模式的关系。Alexander 解释说，当使用模式语言时，“我们总是将其用作顺序，经历模式，总是从较大的模式转移到较小的模式，总是从创建结构的到修饰那些结构的，再到修饰那些装饰的模式。”

模式语言的想法就像适用于适用于建筑物架构一样，也适用于软件开发，而本文始终在使用该术语。软件开发的特点意味着，额外地将用模式语言进行设计的过程自动化是可行的。

就像用 Alexander 的方法一样，您可以通过从较大的模式转移到较小的模式来设计软件系统，如图 1 所示。需要人的专家经验来选择设计环境中适当的软件模式。

图 1. 模式级别

当把模式应用于软件时，有了一个额外的好处：可以将模式的应用自动化，以便当选择模式时，可以用所有与该模式相关的结果展开设计。一个简单的软件模式实例是 Getter/Setter 模式，在该模式中，总是通过一致命名的操作来访问属性。该模式可以自动化，以便将模式应用于类 Customer 的属性名，向 Customer 类添加名为 getName 和 setName（以及恰当的参数）的操作。

通常，将建筑物的物理构建自动化是不可能的。然而，软件系统是用根据实现模式自动生成的信息工件构建的。建筑者必须手工地应用构建模式，而软件架构师可以充分详细地描述软件实现模式，使在已知具体应用环境的时候生成这些模式。

如您在图 2 中所看到的，依据所选择的模式和技术架构原则，详细的系统模型可以转换为一组运行时工件（源代码、部署描述符，等等）。例如，如果您使用了 Getter/Setter 模式的模型，那么您可以针对具体平台，例如 Java?，根据该平台的实现模式，为那些方法生成实现代码。在某些情况下，您可能会使用直接实现了应用模式的实现模式。在其他情况下，您可能要应用多个较低层次的实现模式来实现应用模式。

图 2. 转换

结合模式与 MDD

模式 与 MDD 的互补性是架构驱动开发的关键。模式与 MDD 以下面两种重要的方式相关联：

1.MDD 可以将模式的应用自动化。

传统上，模式是以文档的形式记录下来，UML 常常帮助说明模式。然后手工地应用模式。

2.模式为 MDD 提供内容。

MDD 让您从设计良好的模型转移到设计良好的实现上。模式在建模和实现层获取最佳实践。在不了解应用领域的模式和实现领域的模式的情况下，MDD 是不可能的。

软件模式可以在抽象层（例如设计模式和实现模式）中应用，并可以跨抽象层（将设计元素与代码相关联的模式）应用。您可以将模式组合起来，为解决较大的问题生成复合模式，并为覆盖领域的最佳实践生成模式语言。

当使用本文中介绍的架构驱动的方法来开发时，系统的设计就如图 3 所显示的那样进行。

图 3. 架构驱动的方法

活动的顺序不意味着在下一步开始之前必须完成这一个步骤。我们可以使用迭代的方法，通过多次经过这些步骤，每次添加一些功能来构建解决方案。

利用 IBM 电子商务模式复用资产

利用模式和 MDD 的互补性，利用架构驱动开发方法的项目的成功依赖于模式和 MDD 框架的质量。您必须确保将覆盖了商业、应用和运行时层的模式语言自动化，同时，当应用每个模式时，提供服务和行为的预期质量的定义。IBM 电子商务模式提供了每个层次上的模式，可以让您从中选择特定的模式（根据我们的解决方案需求），来构成您的模式语言。

IBM Patterns for e-business 可以帮助简化资产的复用，通过使未来的合约更简单且更快的方式来获取 IT 架构师的经验。对这些资产的复用节省了时间、金钱和工作量，并且帮助确保坚固的、构架恰当的解决方案的交付。IBM 电子商务模式的目的是获取并发布被使用、测试、并证明是成功的电子商务工件。假定所获取的信息符合大多数，或 80/20 情况。通过最佳实践的方针及相关链接，IBM 电子商务模式在进一步的发展。

分层的资产模型

电子商务模式方法让架构师通过复用来自已证实的成功经验的组件和解决方案元素来实现成功的电子商务解决方案。模式方法是基于一组任何现有的开发方法都可以使用的分层资产。构建分层的资产，以便每个详细的层次构建于前一层次之上。

这些资产包括：

1.商业模式

确定用户、企业和数据之间的交互。

2.整合模式

当不能提供根据单个的商业模式而来的解决方案时，将多个商业模式连在一起。

3.组合模式

表现为通常出现的商业模式和整合模式的组合。

4.应用模式

提供描述了商业模式或整合模式之中的应用程序组件和数据如何交互的概念上的布局。

5.运行时模式

定义了支持应用模式的逻辑中间件结构。

运行时模式描述了主要的中间件节点、它们的角色和这些节点之间的接口。

6.产品映射

为每个运行时模式确定已证实的并测试过的软件实现。

7.最佳实践指导方针

用于电子商务应用程序的设计、开发、部署及管理。

参见图 4，观察可视化的表示。

图 4.

模式和 MDD 是填补商业和 IT 之间鸿沟，并确保商业价值交付的关键。模式及 MDD 的采用：

1.减少了响应的时间

2.使随需的设计和开发成为可能

3.减少复杂性

模式和 MDD 已经成熟，并且正交付着切实的结果。

META Group（现在是 Gartner Group 的一部分）的 Thomas Murphy 所说的“使用模型驱动、基于模式的开发框架和工具的组织，可以获得开发团队中引人注目的生产力和质量提高”得到广泛的引用。

MDD 促进了商业灵活性的提高，这是在不断地随需应变的世界里取得成功的关键。模式驱动开发、IBM 电子商务模式和 MDD 的成功是这些技术的互补性的结果。

IBM 电子商务模式是分层的、可复用的、整合的，且已证实的模式，它向 MDD 方法提供了质量输入。MDD 通过将电子商务模式自动化来增大它们的可复用性，所以它们可以很容易地被再应用。电子商务模式在创建企业级 MDD 框架时提供关键内容，这些框架对于跨企业中的 IT 系统获取并实现公共的架构风格是特别重要的。

系列文章 随需构架解决方案 的第 11 部分很好地说明了此概念。它使用了一个实例，在该实例中，IBM 电子商务模式向 MDD 框架提供输入，用于生成基于消息传递模式的企业服务总线（Enterprise Service Bus，ESB）组件。

总结

在本文中，您了解了如何用模式与 MDD 的组合来进行架构驱动的开发，这样可以明确地获取架构决策，并且在系统中对架构决策自动化编码。您还探究了实现架构驱动方法的好处。