Chapter 2 为什么软件架构很重要？_架构会抑制我们的创造力-优快云博客

1. 架构会抑制或促进系统主导的质量属性。
2. 架构中所作的决定允许你在系统演变时理性地思考和管理变化。
3. 架构的分析使得能够提前预测系统的质量。
4. 记录下来的架构增强了利益相关者之间的沟通。
5. 架构是最早也是最基本的、最难改变的设计决策的载体。
6. 架构定义了后续实现的一系列约束。
7. 架构指示了一个组织的结构，反之亦然。
8. 架构可以为演变性原型提供基础。
9. 架构是允许架构师和项目经理理性思考成本和时间表的关键工件。
10. 可以创建架构作为一个可转移、可重用的模型，成为产品线的核心。
11. 基于架构的开发将注意力集中在组件的组装上，而不仅仅是它们的创建。
12. 通过限制设计替代方案，架构引导开发人员的创造力，减少设计和系统复杂度。
13. 架构可以作为培训新团队成员的基础。

即使你已经相信我们说架构很重要，并且不需要我们再强调十三次，也可以将这十三点（构成本章的大纲）视为在项目中使用架构的十三种有用方法。

抑制或促进系统的质量属性

系统是否能够展示其期望（或要求的）质量属性在很大程度上取决于其架构。

这是一个非常重要的信息，我们在本书的第二部分详细阐述了这一点。在此之前，请将以下几点作为一个起点：

- 如果你的系统要求高性能，那么你需要注意管理元素的时间基本行为，它们对共享资源的使用，以及元素间通信的频率和量。
- 如果可修改性很重要，那么你需要仔细注意为元素分配责任，以便系统的大多数更改只会影响少数元素（理想情况下每次更改只影响一个元素）。
- 如果你的系统必须高度安全，那么你需要管理和保护元素间的通信，并控制哪些元素可以访问哪些信息；你可能还需要在架构中引入专门的元素（如授权机制）。
- 如果你认为可扩展性对你的系统的成功非常重要，那么你需要仔细地定位资源的使用，以便引入更高容量的替代品，并且你必须避免在资源假设或限制中硬编码。
- 如果你的项目需要逐步交付系统的子集，那么你必须仔细管理组件间的使用。
- 如果你希望你的系统中的元素能够在其他系统中重用，那么你需要限制元素间的耦合，这样当你提取一个元素时，它不会因为与当前环境的太多附件而失去其用途。

这些和其他质量属性的策略是非常重要的架构方面。但是，仅仅有架构不能保证系统所需的功能或质量。糟糕的下游设计或实现决策总是可以破坏一个足够好的架构设计。正如我们喜欢说的（多半是开玩笑的）：“架构给予，实现拿走”。从架构设计到编码和实现的生命周期的各个阶段的决策都会影响系统的质量。因此，质量并不完全是架构设计的功能。

一个好的架构是必要的，但不足以确保质量。必须在设计、实现和部署的过程中考虑到实现质量属性。没有一个质量属性完全依赖于设计，也不是完全依赖于实现或部署。满意的结果取决于整体（架构）和细节（实现）的正确性。

例如，可修改性由功能的划分和耦合（架构）以及模块内的编码技术（非架构）决定。因此，一个系统通常是可修改的，如果更改涉及尽可能少的不同元素。然而，尽管有理想的架构，但通过编写晦涩、纠缠不清的代码总是可能使系统变得难以修改。

关于变更的推理和管理

这一点是前一点的推论。

可修改性，即可以轻松对系统进行更改的程度，是一个质量属性（因此涵盖了前一部分的论述），但它是如此重要，以至于我们将其列入“十三要点”名单中。软件开发社区正在认识到一个事实，即典型软件系统的总成本中有大约80%是在初次部署后产生的。这一统计的一个推论是大多数人们正在使用的系统都处于这一阶段。

许多程序员和软件设计师从未有机会参与新的开发工作；他们都是在现有架构和现有代码库的限制下进行工作。几乎所有的软件系统在其生命周期中都会发生变化，以适应新功能，适应新环境，修复错误等。但这些变化往往充满困难。

每个架构将可能的变更划分为三类：本地变更、非本地变更和架构变更。

- 本地变更可以通过修改单个元素来完成。例如，向价格逻辑模块添加新的业务规则。
- 非本地变更需要修改多个元素，但保持基础架构方法不变。例如，向价格逻辑模块添加新的业务规则，然后添加新业务规则所需的数据库新字段，然后在用户界面中显示规则结果。
- 架构变更影响元素之间的基本交互方式，可能需要对系统进行全面更改。例如，将系统从客户端-服务器更改为点对点。

显然，本地变更是最可取的，因此一个有效的架构是其中最常见的变更是本地变更，从而易于实现。

确定何时进行必要的更改，确定哪些更改路径风险最小，评估提议更改的后果，并仲裁请求更改的顺序和优先级都需要对系统软件元素的关系、性能和行为有深入的了解。

这些活动是架构师职责描述中的一部分。推理和分析架构可以提供必要的洞察力来做出有关预期更改的决策。

预测系统品质

以可预测的方式进行。

如果不能在系统开发和部署之前告知已做出适当的架构决策（即系统将展示其所需的质量属性），那么选择一个架构将是一个无望的任务——随机选择架构将与任何其他方法一样表现。幸运的是，仅基于其架构的评估就可以对系统进行质量预测。如果我们知道某些类型的架构决策会导致系统中的某些质量属性，那么我们可以做出这些决策，并有理由期待得到相关的质量属性作为回报。事后，当我们检查一个架构时，我们可以查看是否已做出这些决策，并有信心预测该架构将展示相关的品质。

这与任何成熟的工程学科无异，其中设计分析是开发过程的标准部分。你越早发现设计中的问题，解决它就越便宜、越容易，而且干扰也越小。

即使你没有进行有时确保架构将实现其规定效益的必要的定量分析建模，基于质量属性影响评估决策的这一原则也是非常宝贵的，至少可以及早发现潜在的问题点。

第14章描述的架构建模和分析技术以及第21章介绍的架构评估技术允许我们早期洞察由软件架构实现的软件产品品质。

增强利益相关者之间的沟通

软件架构代表了一个系统的共同抽象，大多数（如果不是全部）系统的利益相关者可以使用它作为创建相互理解、协商、形成共识和相互沟通的基础。架构或其至少部分内容足够抽象，以至于大多数非技术人员可以充分理解它，特别是在架构师的一些指导下，而且该抽象可以被细化为足够丰富的技术规格来指导实施、整合、测试和部署。

一个软件系统的每个利益相关者——客户、用户、项目经理、编码人员、测试人员等——都关心受其架构影响的系统的不同特点。例如：

用户关心系统是否快速、可靠并在需要时可用。
客户关心架构是否可以按照预定的时间表和预算实施。
经理除了关心成本和时间表外，还担心架构是否会允许团队大致独立工作，以有纪律和受控的方式进行交互。
架构师担心实现所有这些目标的策略。

架构提供了一种共同语言，可以在其中表达、协商和解决不同的问题，即使对于大型、复杂的系统也在智力上可管理。没有这样的语言，就很难充分理解大型系统，以做出影响质量和实用性的早期决策。正如我们将在第21章中看到的那样，架构分析既依赖于这个层面的沟通，也增强了它。

第3.5节更深入地探讨了利益相关者及其关切。

承载早期设计决策

软件架构是系统最早的设计决策的体现，这些早期决策对系统的剩余开发、部署和维护生命周期具有极大的影响力。这也是可以审查影响系统的这些重要设计决策的最早时点。

任何设计，无论在任何领域，都可以视为一组决策。当一个艺术家绘画时，他会决定画布的材料，决定记录媒介 —— 油画、水彩、蜡笔 —— 这还是在开始画画之前。一旦开始画画，其他决策立即做出：第一笔是在哪里？它的厚度是多少？它的形状是什么？所有这些早期设计决策对画作的最终外观有很强的影响。每一个决策都限制了接下来的许多决策。每个决策可能单独看起来足够无辜，但早期的决策特别具有不成比例的权重，仅仅因为它们影响和限制了接下来的很多事情。

架构设计也是这样。架构设计也可以视为一组决策。早期的设计决策限制了后续的决策，改变这些决策会产生巨大的影响。改变这些早期的决策会产生连锁反应，需要改变更多的决策。是的，有时架构必须重构或重新设计，但这不是我们轻易采取的任务（因为“连锁反应”可能变成海啸）。

那些由软件架构体现的早期设计决策是什么？考虑以下几点：

系统将运行在一个处理器上还是分布在多个处理器上？
软件会分层吗？如果是，将有多少层？每一层将完成什么工作？
组件将同步还是异步通信？它们通过传输控制还是数据还是两者都传输来交互？
系统将依赖于操作系统或硬件的特定功能吗？
系统中流动的信息将被加密还是不加密？
我们将使用什么操作系统？
我们将选择什么通信协议？

想象一下不得不改变任何这些或无数其他相关决策的噩梦。

这样的决策开始勾勒出架构的一些结构及其交互方式。在第4章中，我们描述了这些早期设计决策的七个类别。在第5-11章中，我们展示了这些设计决策类别在实现质量属性上的影响。

定义实现上的约束

如果实现符合由架构规定的设计决策，则它展示了一个架构。这意味着实现必须按照规定的元素集来实现，这些元素必须按照规定的方式相互交互，而且每个元素都必须根据架构的规定来履行其对其他元素的责任。这些规定中的每一项都是对实施者的约束。

元素构建者必须精通他们各自元素的规格，但他们可能不了解架构交易的影响 —— 架构（或架构师）只是以一种方式限制他们，以满足交易的要求。这种现象的一个典型例子是当架构师为涉及某更大功能片段的软件分配性能预算时。如果每个软件单位都保持在其预算内，那么整体交易将满足其性能要求。构成每个组成部分的实施者可能不知道总体预算，只知道他们自己的。

相反，架构师不需要成为算法设计的所有方面的专家或编程语言的复杂性的专家 —— 尽管他们当然应该知道足够多的信息，以避免设计出难以构建的东西 —— 但他们是负责建立、分析和执行架构权衡的人。

影响组织结构

架构不仅规定了正在开发的系统的结构，而且该结构会被铭刻在开发项目的结构中（有时甚至是整个组织的结构中）。在大型项目中分配劳动的常规方法是将不同的系统部分分配给不同的团队来构建。这被称为系统的工作分解结构。由于架构包括系统的最宽泛的分解，它通常用作工作分解结构的基础。工作分解结构反过来又决定了规划、调度和预算的单位；团队间的通讯渠道；配置控制和文件系统组织；集成和测试计划和程序；甚至是项目的细节，如项目内部网络的组织和公司野餐时谁与谁坐在一起。团队之间通过主要元素的接口规格进行交流。当启动维护活动时，它也会反映软件结构，形成特定的维护团队来维护来自架构的特定结构元素：数据库、业务规则、用户界面、设备驱动程序等。

建立工作分解结构的一个副作用是冻结软件架构的某些方面。负责其中一个子系统的团队会反对将其职责分散到其他团队中。如果这些职责已经在合同关系中得到正式化，那么改变职责可能变得代价高昂甚至产生诉讼。

因此，一旦达成架构协议，由于管理和业务原因，对其进行重大修改将变得非常昂贵。这是进行大量分析的一个论点（其中之一），在确定大型系统的软件架构之前，因为有很多事情依赖于它。

启用进化原型构建

一旦架构被定义，它就可以被分析和作为一个基本系统（skeletal system）进行原型构建。基本系统是一个在大部分系统功能被创建之前已经构建了一些基础设施的系统 — 如元素的初始化、通信、数据共享、资源访问、错误报告、活动日志等。

例如，以插件架构构建的系统就是基本系统：插件提供实际功能。这种方法有助于开发过程，因为系统在产品生命周期的早期阶段就可以执行。随着存根实例化或原型部件被完整版本替换，系统的保真度会增加。在某些情况下，原型部分可以是最终功能的低保真版本，或者它们可以是代理，以适当的速率消耗和产生数据，但做的很少。这种方法还允许在产品生命周期的早期阶段识别潜在的性能问题。

这些好处降低了项目中的潜在风险。此外，如果该架构是一系列相关系统的一部分，那么创建原型框架的成本可以分摊在许多系统的开发上。

提高成本和时间表估算

成本和时间表估算对项目经理来说是重要的工具，不仅可以用来获取所需的资源，还可以用来监控项目的进度，知道项目是否遇到了困难及何时会遇到困难。架构师的职责之一是在项目生命周期的早期阶段帮助项目经理创建成本和时间表估算。虽然自上而下的估算对于设定目标和分配预算是有用的，但是基于自下而上理解系统各个组件的成本估算通常比纯粹基于自上而下的系统知识更准确。

如我们所说，项目的组织结构和工作分解结构几乎总是基于其架构。每个负责工作项目的团队或个人将能够为他们的部分做出更准确的估算，比项目经理更有能力，并且会更有动力使估算成为现实。但是最好的成本和时间表估算通常会来自于自上而下估算（由架构师和项目经理创建）和自下而上估算（由开发人员创建）之间的共识。由此产生的讨论和协商创建了比任一方法单独使用更为准确的估算。

如果系统的要求已经过审查和验证，这将大有帮助。你对范围的预先知识越多，成本和时间表的估算就会越准确。第22章深入探讨了项目管理中架构的使用。

提供一个可转移、可重用的模型

在生命周期的更早阶段应用重用，可以实现更大的好处。虽然代码重用可以提供好处，但对于具有类似要求的系统来说，架构的重用可以提供巨大的杠杆效应。不仅可以重用代码，还可以重用导致最初架构的要求，以及在构建重用架构时获得的经验和基础设施。当可以在多个系统中重用架构决策时，我们刚刚描述的所有早期决策后果也会被转移。

软件产品线或家族是一组所有使用相同的可重用资产构建的软件系统。这些资产中最主要的是为满足整个家族的需求而设计的架构。产品线架构师选择一个架构（或一系列紧密相关的架构）来服务产品线的所有预期成员。架构定义了产品线的所有成员的固定内容和可变内容。软件产品线代表了一种强大的多系统开发方法，它在上市时间、成本、生产力和产品质量方面展示了数量级的回报。架构的力量处于这一范例的核心。与其他资本投资类似，产品线的架构成为开发组织的核心资产。第25章解释了软件产品线。

允许整合独立开发的组件

虽然早期的软件范例将编程作为主要活动，以代码行数来衡量进度，但基于架构的开发通常关注于组合或装配可能已经分别甚至独立开发的元素。这种组合是可能的，因为架构定义了可以整合到系统中的元素。架构根据它们如何与环境互动，如何接收和放弃控制，它们消耗和产生什么数据，如何访问数据以及它们用于通信和资源共享的协议来限制可能的替换（或添加）。

在1793年，Eli Whitney基于互换部件的原则对火枪进行大规模生产，标志着工业时代的开始。在物理测量可靠之前，制造可互换的部件是一个艰巨的任务。现在在软件领域，直到抽象可以可靠地限定，结构可互换的概念同样令人生畏和同样重要。

商业现成的组件、开源软件、公开可用的应用程序和网络服务都是Whitney基本理念的现代软件实例。Whitney的火枪部件有“接口”（与适合和耐用性有关），今天的可互换软件组件也是如此。

对于软件来说，回报可以是

减少上市时间（使用别人的现成解决方案应该比自己构建更容易）
增加可靠性（广泛使用的软件应该已经解决了其错误）
降低成本（软件供应商可以将开发成本分摊到他们的客户群上）
灵活性（如果你想购买的组件不是特别专用，那么它很可能可以从多个来源获得，从而增加你的购买力）

限制设计方案的词汇

随着有用的架构模式的收集，我们明白，虽然软件元素可以以无限多种方式组合在一起，但通过自愿限制我们对元素及其交互的选择到相对较少的数量有一些东西可以获得。通过这样做，我们最小化了我们正在构建的系统的设计复杂性。

软件工程师不是艺术家，其创造力和自由是最重要的。工程学是关于纪律的，而纪律部分来源于将方案的词汇限制到经过验证的解决方案。这种方法的优点包括增强复用，更规则和更简单的设计，更容易理解和交流，更有能力的分析，更短的选择时间和更大的互操作性。架构模式指导架构师，并通过将设计方案的词汇限制到相对较少的数量来聚焦架构师对感兴趣的质量属性。

软件设计的属性源自架构模式的选择。那些更适合特定问题的模式应该改善实现的设计解决方案，可能是通过使仲裁冲突的设计约束更容易，增加对不理解的设计环境的洞察力，或帮助暴露需求中的不一致性。我们将在第13章中更详细地讨论架构模式。

提供培训基础

架构，包括描述元素如何相互交互以实现所需行为的描述，可以作为新项目成员对系统的第一次介绍。这强化了我们的观点，软件架构的一个重要用途是支持和鼓励各种利益相关者之间的沟通。架构是一个共同的参考点。

模块视图非常适合向某人展示项目的结构：谁做什么，哪些团队被分配到系统的哪些部分，等等。组件和连接器视图非常适合解释系统预期如何工作并完成其任务。

我们将在第18章中更详细地讨论这些视图。

总结

软件架构因多种技术和非技术原因而变得重要。我们的列表包括以下内容：

1. 一个架构将抑制或促进系统的主导质量属性。
2. 架构中做出的决策允许您在系统演变时推理和管理变化。
3. 架构分析使得可以早期预测系统的质量。
4. 记录的架构增强了利益相关者之间的沟通。
5. 架构是携带最早期、因此是最基本、最难改变的设计决策的载体。
6. 架构定义了一系列后续实现的约束。
7. 架构决定了一个组织的结构，反之亦然。
8. 架构可以为进化原型提供基础。
9. 架构是允许架构师和项目经理推理成本和时间表的关键工件。
10. 架构可以被创建为一个可转移、可重用的模型，成为产品线的核心。
11. 基于架构的开发将注意力集中在组件的组装上，而不仅仅是它们的创建。
12. 架构引导开发人员的创造力，减少设计和系统复杂性。
13. 架构可以成为新团队成员培训的基础。