1. 什么是软件架构？

我们被叫来担任未来的架构师，而不是当它的受害者。

—R. Buckminster Fuller

之所以撰写（就我们而言）和阅读（你对来说）一本关于软件架构（它浓缩了许多人的经验）的书，是因为我们认为

1. 拥有合理的软件架构对于软件系统开发的成功非常重要，并且
2. 关于软件架构的知识体系足以写满一本书。

曾经有一段时间，这两种假设都有待证明。本书的早期版本试图让读者相信这两个假设都是正确的，在你被说服之后，为你提供基础知识，以便你可以自行应用架构实践。今天，关于这两个目标似乎没有什么争议，所以这本书更多的是关于提供指导而不是说服读者。

软件架构的基本原则是，每个软件系统都是为了满足组织的业务目标而构建的，并且系统的架构是这些（通常是抽象的）业务目标与最终（具体）系统之间的桥梁。虽然从抽象目标到具体系统的过程可能很复杂，但好消息是，可以使用已知技术来设计、分析和记录软件架构，以支持实现这些业务目标。复杂性可以被驯服，变得易于处理。

这些就是本书的主题：设计、分析和记录架构。我们还将研究这些活动的影响因素，主要是以导致质量属性需求的业务目标。

在本章中，我们将严格从软件工程的角度关注架构。也就是说，我们将探索软件架构为开发项目带来的价值。后面的章节将从业务和组织的角度进行讨论。

1.1 软件架构是什么和不是什么

可以从网上轻松找到许多软件架构的定义，但我们喜欢这个：

系统的软件架构是推理系统所需的一组结构。这些结构包括：软件元素、它们之间的关系以及两者的属性。

这个定义与其他谈论系统“早期”、“重大”或“重要”决策的定义形成鲜明对比。虽然许多架构决策确实是在早期做出的，但并非所有决策都是，尤其是在敏捷（Agile）和螺旋式开发项目中。同样，有许多早期做出的决策并不是我们所认为的架构。此外，很难看到一个决定并判断它是否“主要的”。有时只有时间会证明一切。由于决定架构是架构师最重要的职责之一，我们需要知道架构由哪些决策组成。

相比之下，结构在软件中很容易识别，它们构成了系统设计和分析的强大工具。

所以，定义就变成这样：架构是关于让人推理的结构。

让我们看一下我们的定义的一些含义。

架构是一组软件结构的集合

这是我们定义的第一个也是最明显的含义。结构只是一组由关系结合在一起的元素。软件系统由许多结构组成，没有一个结构可以声称其是架构。结构可以分组到不同的类别中，而类别本身则提供了思考架构的有用方法。架构性的结构（architectural structure）可以分为三个有用的类别，它们将在架构的设计、文档和分析中发挥重要作用：

1. 组件和连接结构
2. 模块结构
3. 分配结构

我们将在下一节中深入探讨这些类型的结构。

尽管软件包含无数的结构，但并非所有结构都是架构性的。例如，把包含字母“z”的源代码行集，按长度从短到长递增排序，也是一种软件结构。但这既不有趣，也不关乎架构。如果结构能够帮助你推理系统和系统属性，那么该结构就是架构性的。推理应该是与（对某些利益相关者很重要的）系统属性相关。这些属性包括系统实现的功能、系统在面对缺陷或试图将其关闭时保持有效运行的能力、对系统进行特定更改的难易程度、系统对用户请求的响应能力等等。在本书中，我们将花费大量时间探索架构与诸如此类的 质量属性（quality attributes） 之间的关系。

因此，架构的集合既不固定也没限制。什么是架构取决于在您的系统上下文中哪些有助于推理（reason）系统。

架构是一种抽象

由于架构由结构组成，而结构由元素¹和关系组成，因此架构由软件元素以及这些元素的关系组成。这意味着架构明确而刻意地省略了有关元素的某些信息，这些信息对系统推理没有用。因此，架构首先是系统的“抽象”，它选择某些细节并掩盖了其他细节。在所有现代系统中，元素通过接口来交互的，这些接口将有关元素的详细信息划分为公共部分和私有部分。架构关注的是这个部分的公共方面；元素的私有细节（仅与内部实现有关的细节）不是架构上的。这种抽象对于驾驭架构的复杂性至关重要：我们根本无法也不想一直处理所有的复杂性。我们希望（且需要）让理解系统架构比理解该系统的每个细节容易许多。即使是适度的规模的系统，你不能把一个系统的每一个细节都记在脑海里；架构的意义在于让你不必这样做。

架构和设计

架构是设计，但并非所有设计都是架构。也就是说，许多设计决策不受架构的约束（毕竟架构是一种抽象），并且取决于下游设计者或实现者的审慎和良好的判断力。

每个软件系统都有软件架构

每个系统都有一个架构，因为每个系统都有元素和关系。但是，这并不意味着任何人都知道该架构。也许所有设计系统的人都早已不在了，文档已经遗失了（或从未产生过），源代码已经丢失（或从未交付过），我们手头只有可执行的二进制码。这揭示了系统的架构与该架构的表现（representation）之间的差异。鉴于架构可以独立于其描述或规范而存在，这就提出了 第 22 章 中描述的架构文档的重要性。

不是所有的架构都是好的

我们的定义无关于系统的架构是好的还是坏的。架构可能有助或妨碍实现系统的重要需求。如果我们不接受试错作为为系统选择架构的最佳方式（也就是说，随机选择一个架构以其构建系统，并不断改进以期最后得到最好的结果），那么 第20章 架构设计 和 第21章 架构评估 就显示出其重要性了。

架构包含行为

每个元素的行为都是架构的一部分，因为该行为可以帮助您推理系统。元素的行为体现了它们如何相互交互以及与环境交互。这显然是我们架构定义的一部分，并且会影响系统所展示的属性，例如其运行时的性能。

行为的某些方面超出了架构师的关注范围。但是，如果元素的行为会影响整个系统的可接受性，则必须将此行为视为系统架构设计的一部分，并且应将其记录在案。

系统和企业架构

系统架构和企业架构是与软件架构相关的两个学科。这两个学科都比软件关注的更广泛，并通过建立软件系统及其架构师必须遵守的约束来影响软件架构。

系统架构

系统的架构是系统的一种表示形式，将功能映射到硬件和软件组件上，将软件架构映射到硬件架构上，并关注人类与这些组件的交互。也就是说，系统架构关注的是硬件、软件和人的整体。

例如，系统架构将影响分配给不同处理器的功能以及连接这些处理器的网络类型。软件架构将决定该功能的结构以及驻留在各个处理器上的软件程序如何交互。

对软件架构的描述，因为它映射到硬件和网络组件，允许推理性能和可靠性等质量。对系统架构的描述将允许对功耗、重量和物理尺寸等其他质量进行推理。

在设计特定系统时，系统架构师和软件架构师之间经常就功能的分布进行协商，从而对软件架构施加约束。

企业架构

企业架构是对组织流程、信息流、人员和组织子单位的结构和行为的描述。企业架构不需要包括计算机化的信息系统——显然，在计算机出现之前，组织拥有符合上述定义的架构——但如今，如果没有信息系统的支持，除了最小的企业之外，所有企业的企业架构都是不可想象的。因此，现代企业架构关注的是软件系统如何支持企业的业务流程和目标。这组关注点中通常包括一个过程，用于决定企业应支持哪些系统具有哪些功能。

例如，企业架构将指定各种系统用于交互的数据模型。它还将指定企业系统如何与外部系统交互的规则。

软件只是企业架构的一个关注点。人类如何使用软件来执行业务流程以及确定计算环境的标准是企业架构解决的另外两个常见问题。

有时，支持系统之间以及与外部世界通信的软件基础架构被认为是企业架构的一部分；在其他时候，此基础结构被视为企业中的系统之一。（无论哪种情况，该基础设施的架构都是软件架构！这两种观点将导致与基础设施相关的个人有不同的管理结构和影响范围。

这些学科是否在本书的范围内？是的！（嗯，没有。）

系统和企业为软件体系结构提供了环境和约束。软件架构必须存在于系统和企业中，并且越来越成为实现组织业务目标的重点。企业和系统架构与软件架构有很多共同之处。所有这些都可以设计、评估和记录；全部符合要求；所有这些都旨在满足利益相关者；都由结构组成，而结构又由元素和关系组成；所有人都有一套模式供各自的架构师使用；这样的例子不胜枚举。因此，就这些架构与软件架构的共同点而言，它们在本书的讨论范围内。但像所有技术学科一样，每个学科都有自己的专业词汇和技术，我们不会涵盖这些。还有很多其他来源可以这样做。

架构结构和视图

---

---

---

1. In this book, we use the term “element” when we mean either a module or a component, and don’t want to distinguish between the two. 在本书中，我们并不想区分模块（module）或组件（component），统一使用术语“元素（element）”代替它们。 ↩︎