TOGAF—架构模式
本章提供使用体系结构模式的指南。
4.1 引言
描述企业架构的模式对从业者来说变得越来越重要。多样化和 企业架构的多学科性质要求在不同的学科、领域和 详细级别。
该标准的先前版本由于缺乏成熟度而没有完全接受架构模式。今天 许多组织正在使用模式来描述其不同级别的体系结构，从软件设计模式到 商业模式。确实没有描述企业架构模式的单一标准。然而，它 可以说是有模式来描述模式的。
4.1.1 背景
“模式”被定义为：“在一个实际环境中有用并且可能在其他实际环境中有用的想法” （来源：Analysis Patterns — Re-use Object Models，作者：M. Fowler）。
在 TOGAF 标准中，模式被认为是将构建块置于上下文中的一种方式;例如，要描述 问题的可重用解决方案。构建块是你使用的：模式可以告诉你如何使用它们，何时使用，为什么使用，以及什么 在这样做时，您必须做出权衡。模式提供了帮助架构师识别组合的承诺 架构和/或解决方案构建块 （ABB/SBB），过去已被证明可以提供有效的解决方案，并且可能 为未来有效的解决方案提供基础。
图案技术被普遍认为是一种有价值的建筑设计技术 建筑建筑师克里斯托弗·亚历山大（Christopher Alexander）在他的著作《永恒的建筑方式》（The Timeless Way of Building）中描述了这种方法， 1979年出版。本书介绍了使用模式背后的思想，亚历山大随后又介绍了两个 其他书籍（A Pattern Language 和 The Oregon Experiment），其中他扩展了对特征的描述 以及架构模式方法的好处。
软件和建筑架构师有许多类似的问题需要解决，因此软件架构师很自然地采取 对模式作为建筑工具的兴趣。自亚历山大1979年出版以来，已经发表了许多关于它们的论文和书籍， 也许最著名的是设计模式：可重用面向对象软件的元素（Gamma et al.， 1994）。这 本书描述了面向对象软件设计中特定问题的简单而优雅的解决方案。
4.1.2 图案的内容
文献中使用了几种不同的格式来描述模式，并且没有一种格式能够广泛传播 接受。但是，对于模式应包含的事物类型存在广泛的共识。以下标题是 摘自《面向模式的软件架构：模式系统》（Buschmann et al.， 1996）。所描述的元素 下面将在大多数模式中找到，即使使用不同的标题来描述它们。
名字
一种有意义且令人难忘的方式来引用模式，通常是单个单词或短语。
问题
对问题的描述，说明应用模式的意图——预期目标和要达到的目标 在下文所述的背景和力量范围内（也许可以指出其优先事项）。
上下文
模式适用的前提条件 — 模式之前初始状态的描述 应用的。
力量
描述相关的力量和约束，以及它们如何相互作用/冲突以及与预期 目标和目的。描述应澄清问题的复杂性，并明确说明以下权衡 必须考虑。（这种权衡的需要通常是使问题变得困难的原因，并产生对 首先是模式。“力”的概念在许多方面等同于建筑师寻求优化的“品质”，并且 他们在设计架构时寻求解决的问题。例如：
- 安全性、稳健性、可靠性、容错性
- 可管理性
- 效率、性能、吞吐量、带宽要求、空间利用率
- 可扩展性（按需增量增长）
- 可扩展性、可进化性、可维护性
- 模块化、独立性、可重用性、开放性、可组合性（即插即用）、可移植性
- 完整性和正确性
- 易于施工
- 易于使用
- 等。。。。
溶液
使用文本和/或图形描述如何实现预期目标。描述应标识 解决方案的静态结构及其动态行为 - 人员和计算参与者，以及他们的协作。这 说明可能包括实现解决方案的准则。解决方案的变体或专用化也可能是 描述。
生成的上下文
应用模式后的后置条件。实施解决方案通常需要在竞争者之间进行权衡 力量。
此元素描述哪些力已解决以及如何解决，哪些力仍未解决。它也可能指示其他模式 这可能适用于新的情况。（模式可能是实现某个更大目标的一个步骤。任何此类其他模式 将在相关模式下详细描述。
例子
模式的一个或多个示例应用程序，用于说明其他每个元素：特定问题、上下文和 一组力;如何应用模式;以及生成的上下文。
理由
对整个模式或其中单个组件的解释/理由，指示模式如何 实际上有效，以及为什么 - 它如何解决实现预期目标和目的的力量，以及为什么这是“好的”。这 模式的解决方案元素描述了解决方案的外部结构和行为：基本原理提供了对 其内部工作原理。
相关模式
此模式与其他模式之间的关系。这些可能是前置模式，其生成的上下文对应于 这个的初始背景;或后续模式，其初始上下文对应于此模式的结果上下文;或 替代模式，描述同一问题的不同解决方案，但受到不同的力量;或共同依赖 模式，可以/必须与此模式一起应用。
已知用途
该模式在现有系统中的已知应用，验证该模式确实描述了一个经过验证的解决方案 反复出现的问题。已知用途也可以作为示例。
模式也可以以摘要开头，提供模式的概述并指出它解决的问题类型。 摘要还可以确定目标受众以及对读者的假设。
4.1.3 术语
尽管设计模式多年来一直是软件行业广泛关注的焦点，尤其是在 在面向对象和基于组件的软件领域，直到最近才对 架构模式 — 将设计模式的原则和概念扩展到架构领域。
与该领域相关的技术文献由于软件领域的许多人使用该术语而变得复杂。 “架构”指的是软件，而许多模式被描述为“架构模式”都是高级软件设计 模式。这只会使术语的精确使用变得更加重要。
4.1.3.1 架构模式和设计模式
术语“设计模式”通常用于指解决软件架构、设计或 编程实施。在《面向模式的软件体系结构：模式系统》一书中，作者定义了这三者。 模式类型如下：
- 架构模式表示软件系统的基本结构组织或模式
它提供了一组预定义的子系统，指定了它们的职责，并包括组织规则和准则。 它们之间的关系。
- 设计模式提供了一种方案，用于优化软件系统的子系统或组件，或关系 他们之间
它描述了一种经常重复出现的通信组件结构，该结构解决了特定组件中的一般设计问题 上下文。
- 习语是特定于编程语言的低级模式
一个习语描述了如何使用 给定语言。
这些区别很有用，但重要的是要注意，在这种情况下，体系结构模式仍然仅指 软件架构。软件架构当然是 TOGAF 标准重点的重要组成部分，但它不是它的 只有专注。
在本节中，我们将关注企业系统架构的模式。这些类似于软件架构 和设计模式，并借用他们的许多概念和术语，但专注于提供可重用的模型和方法 专门用于企业信息系统（包括软件、硬件、网络和人员）的架构 反对纯粹的软件系统。
4.1.3.2 模式和架构连续体
尽管架构模式（尚未）集成到 TOGAF 标准中，但前四个主要阶段中的每一个 ADM（阶段 A 到 D）指示企业中相关的可重用架构资产所处的阶段 应考虑使用架构连续体。架构模式就是这样一种资产。
采用正式方法来使用和重用架构模式的企业通常会集成它们的使用 进入企业架构连续体。
4.1.3.3 模式和视图
架构视图是一个或多个模型的选定部分，代表一个完整的系统架构，重点是那些 解决一个或多个利益相关者关注的方面。模式可以为设计此类模型和组合提供帮助 基于它们的观点。
4.1.3.4 模式和业务场景
在业务方案的工作中，可以很好地识别相关的体系结构模式。