1.1 软件架构含义

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

系统软件架构是对系统进行推理的一组结构，它需要包含软件元素、元素之间的关系，以及它们的属性。

一、架构是一组软件结构

结构简单的说，就是一组元素通过一个关系连接在一起，而软件系统由很多的结构组成的。
架构结构分为三类，它们在架构的设计、记录和分析中发挥着重要使用：
1 一些结构将系统划分为实现单元，这些结构我们称为模块。模块是多团队进行工作拆分的依据，例如DB团队负责DB的开发与管理，规则团队负责规则的开发，用户接口团队用户接口的开发等，这种结构也叫模块分解结构。除此之外，还有作为面向对象分析和设计类图输出的模块结构，以及分层聚合模块结构。模块结构都是静态结构，主要目标是将系统的功能拆解到不同的实现团队执行。
2 其他结构都是动态的，主要关注于元素在运行时如何互相影响以实现系统功能。假设系统将被建成一组服务。这些服务，与之交互的基础设施，以及跟其他结构的同步和互相影响关系常用于描述系统的结构。这些服务由各种实现单元中的程序组成。这种运行时结构叫组件连接器结构（C&C）结构，这里的组件是指运行时实体。
3 另一种结构描述了从软件结构到系统的组织、开发、安装和执行环境的映射。例如，模块被分配到团队进行开发，并分配给文件结构用于实现、集成和测试的位置。组件被部署到硬件去执行，这些映射被称为分配结构。

尽管软件是由无数的结构组成，但并不是所有结构都是架构化的。例如，包含字母“z,"并且根据长度从短到长排序的一组源代码行集合，是一种软件结构。但这既不是一件很有趣的事，也不是架构化的。判断结构是不是架构化的标准是，它提供了系统及系统属性推理。这种推理必须是对利益干系者非常重要的系统属性。这些属性包知系统功能实现、系统容错能力、对系统进行定制的难度，以及对用户请求的系统响应能力等等。因此，架构的结构集合是不固定的也是无限的，只要在系统上下文中有用的内容就是架构设计。

二、架构是一种抽象概念

由于架构是由结构组成，而结构由元素和关系组成，因此可以认为，架构是由软件元素及这些元素的联系关系组成的。这表示架构特别忽略某些对解释系统无用的信息，特别是，它会忽略没有衍生物的单一元素信息。因此，一个架构首先是一个系统的抽象，它选择某些细节并忽略其他细节。在所有的现代系统中，元素通过接口相互作用，接口将元素的细节划分为公共部分和私有部分。架构会关心公共部分的详细内容，但不会关心私有细节及仅与内部实现相关的内容。除了这些接口外，架构抽象让我们可以从元素的角度看待系统，元素是如何排列的，它们是如何交互的，它们是如何组成的，它们支持我们的系统推理的属性是什么，等等。这种抽象对于驯服一个系统的复杂性是必不可少的，我们根本不能，也不想一直处理所有的复杂性。

三、每个软件系统都有一个软件架构

每个系统都是由元素及元素间的关系组件的。在最简单的情况下，系统本身就是一个单一的元素——一个无趣的并且可能是无用的架构，但仍然是一个架构。即使每个系统都有架构，这并不代表这个架构是肯定被所有人知道的。也许那些设计系统的人都走了，也许文档遗失了（或者根本没有创建），也许源代码遗失了（或者没有交付），我们有的只是一个可运行的二进制文件。由于一个架构可以独立于它的描述或规范存在，这就提升了架构说明文档和架构重构的重要性。

四、架构应包含行为

每个元素的行为都是架构的一部分，因为这些行为可以用来对系统进行推理。这些行为体现了元素是如何与其他元素互相影响的。这也告诉我们，那些被当作架构的框线图，实际上根本不是是架构。读者根可能会通过一些数据库、用例接口图、执行图等方框去理解相应元素的功能和行为。这种想像有点接近于一个架构，但它源于观察者的想像，依赖于不存在的信息。这并不意味着所有情况下都必须记录每个元素的精确行为和性能——一些行为的某些方面是细粒度的，低于架构师的关注级别的。但另一方面，一个元素的行为影响其他元素影响整个系统的兼容性时，这些行为是必须被作为架构的一部分进行考虑和记录的。

五、并不是所有的架构都是好的架构

架构可能允许或附上系统实现其行为、质量属性和生命周期需求。假设我们不把试错法作为一个选择系统架构的最好方法，而是随机选择一个架构，并且根据这个架构去构建系统，然后黑客攻击测试并希望得到最好的结果，这就提高了架构设计的重要性和价值。

附：系统架构和企业架构

与软件架构关联比较紧密的，是系统架构和企业架构。这两种架构都比软件有更广泛的关注点，并通过建立软件系统必须存在的约束来影响软件架构。在这两种情况下，系统的软件架构师都应该在为有关系统或企业的决策提供输入的团队中。

系统架构

系统架构是一个系统的包含功能到硬件、软件组件的映射，包含软件架构到硬件架构映射，与这些组件间相互影响有关的展现。也即是说，系统架构与整个系统有关，包括硬件、软件和人。

例如，系统架构会决定被分配到不同处理器的功能以及连接到这些处理器的网络类型。在每个处理器上的软件架构会决定这些功能是如何实现的，以及各个处理器是如何通过网络上的信息交换进行交互的。

软件体系结构的描述映射到硬件和网络组件，允许对性能和可靠性等质量进行推理。对系统架构的描述将允许对额外的质量进行推理，如功耗、重量和物理足迹。当设计一个特定的系统时，系统架构师和软件架构师之间经常会就功能的分布以及因此对软件体系结构施加的约束进行协商。

企业架构

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

企业架构会指定例如各种系统用于交互的数据模型。也会指定企业系统与外部系统交互的规则。

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

有时候提供系统及系统与外部世界的联系软件基础设施被认为是企业架构的一部分；有时候，这些基础设施被认为是企业中的一个系统。（无论哪种情况，基础设施的体系结构都是软件体系结构！）这两种观点将导致与基础设施相关的个人产生不同的管理结构和影响范围。

系统和企业为软件体系结构提供环境和约束。软件体系结构必须存在于系统和企业中，并且越来越成为实现组织业务目标的焦点。但所有三种架构形式都有重要的共同点：它们关注作为抽象的主要元素，元素之间的关系，以及元素如何共同满足所构建事物的行为和质量目标。