软件架构I：基础概念

本书讨论如下内容：

• 架构模式：许多架构决策的技术基础。
• 组件：识别、耦合、内聚、分区和粒度。
• 软技能：有效的团队管理、会议、谈判、演示等。
• 现代性：在过去几年中发生了根本性变化的工程实践和操作方法。
• 架构作为一门工程学科：可重复的结果、指标和具体的评估为软件体系结构增加了严格性。

"软件架构师"职位出现在众多最佳职位列表的顶部。但却没有科学的方法教授如何成为架构师的原因？

• 首先，业界对软件架构本身没有很好的定义。
• 第二，软件架构师的角色的职责范围不断地扩大。
• 第三，由于快速发展的软件开发生态系统，软件架构的目标不断发生变化。
• 第四，关于软件架构的许多材料都已成为过去时。

软件架构由系统的结构（表示支持架构的粗黑线）和系统必须支持的架构特征（``-ilities''）、架构决策以及最终的设计原则组成。

软件架构组成

系统的结构是指系统所实现的架构样式的类型（如微服务，分层或微内核）。 仅通过结构来描述架构并不能完全阐明架构。

系统的结构

架构特征是定义软件架构的另一个维度。 架构特征定义了系统的成功标准，该标准通常与系统的功能正交。 请注意，列出的所有特征都不需要了解系统功能，但是它们是使系统正常运行所必需的。

架构特征

架构决策定义了应如何构建系统的规则。

架构决策

如果由于某种条件或其他约束而无法在系统的某个部分中实施特定的体系结构决策，则可以通过称为方差的方法打破该决策（或规则）。 大多数组织都有架构审查委员会（ARB）或首席架构师使用的差异模型。 这些模型将寻求与特定标准或架构决策的差异的过程形式化。 ARB将分析特定架构决策的例外情况（如果没有ARB，则由首席架构师进行分析），并根据理由和权衡取舍批准或拒绝该例外情况。

设计原则与体系结构决定的不同之处在于，设计原则是一种准则，而不是一成不变的规则。

与给定的角色，职务或职位描述无关，对软件架构师有八项核心期望：

• 制定架构决策
  期望架构师定义用于指导团队、部门或整个企业的技术决策的架构决策和设计原则。
• 持续分析架构
  期望架构师不断分析架构和当前技术环境，然后提出改进建议。
• 紧跟最新趋势
  希望建筑师能够了解最新的技术和行业趋势。
• 确保遵守决定
  期望架构师确保遵守架构决策和设计原则。
• 多样的曝光和经验
  架构师应具有多种多样的技术、框架、平台和环境。
• 具有业务领域知识
  架构师应具备一定水平的业务领域专业知识。
• 具有人际交往能力
  建筑师应具备出色的人际交往能力，包括团队合作、促进和领导才能。
• 了解和驾驭政治
  期望架构师了解企业的政治氛围并能够驾驭政治。

image.png

架构交叉点

• 工程实践
  传统上，软件体系结构与用于创建软件的开发过程是分开的。 存在数十种流行的方法来构建软件，包括瀑布式和许多敏捷的风格（例如Scrum方法、极限编程、精益和Crystal方法），这些方法大部分不会影响软件体系结构。
• 运维/DevOps
  由于对架构公认的一些重新思考，DevOps的出现是架构与相关领域之间最近最明显的交集。 多年以来，许多公司都将运维视为与软件开发分开的功能。 他们通常将运维外包给另一家公司以节省成本。 在1990年代和2000年代设计的许多架构都假定架构师无法控制运维，并且围绕该限制进行防御性的构建。
• 流程
  另一个公理是，软件架构通常与软件开发过程正交。构建软件（过程）的方式对软件架构（结构）的影响很小。因此，尽管团队使用的软件开发过程对软件架构有一定影响（特别是在工程实践方面），但从历史上看，它们大多是分开的。大多数有关软件架构的书都忽略了软件开发过程，对可预测性等问题做出了虚假的假设。但是，团队开发软件的过程会影响软件架构的许多方面。例如，由于软件的性质，在过去的几十年中，许多公司都采用了敏捷开发方法。敏捷项目中的架构师可以进行迭代开发，因此可以更快地反馈决策。反过来，这使架构师可以更加积极地进行实验以及依赖反馈的其他知识。
• 数据
  应用程序开发中有很大一部分包括外部数据存储，通常是关系数据库（或越来越多的NoSQL）。 但是，许多有关软件架构的书都只包含对架构这一重要方面的简要介绍。 代码和数据具有共生关系：没有其他代码，一个代码就无用。

软件架构法则

软件体系结构中的所有内容都是一个折衷方案。 ——软件架构第一定律
为什么比如何更重要。 ——软件架构第二定律