［读书笔记］恰如其分的软件架构－概述

第1章  概述

1.1  分治、知识与抽象

开发者把问题分割为规模更小且易于处理的若干子问题，这样他们就可以运用相似的问题的知识来解决某些子问题，而且使用抽象有助于他们进行推理和判断。

分治、知识、抽象的有效性在于它们能帮助我们在不变的智力条件下理解不断增长的问题。

分治：分割后的各个部分小到可以由一个人解决；必须考虑如何将各个部分装配为整体。

知识：从先前问题中学习得到的知识来解决当前的问题。

抽象：能够精简问题空间，问题越小越容易理解，能够有效解决软件的复杂度及规模增长带来的问题。

软件架构证实这样的武器，它能帮助解决软件系统的复杂度及规模增长带来的问题。

它有助于分割软件系统，提供有助于设计出更优秀软件的知识，提供有助于理解软件的抽象。

1.2  软件架构的三个案例

使用以下三个系统满足查询邮件日志的功能：

1）本地日志文件

2）中央数据库

3）所以簇

1.3  反思

它们的架构与功能是完全独立的。

质量属性：尽管功能相同，不同版本的系统却展现了不同的可修改性、可伸缩性及延迟时间。需谨记，提升一种质量就会抑制另一种，因为这些质量属性之间的影响通常会相互抵消。

概念模型：在脑海中形成概念模型，有助于理解所见到的内容。

抽象与约束：既要见微知著，也需要有效推理。

1.4  视角转换

新的架构抽象理念并未否定过去，而是兼容并包。若要有效地运用软件架构思想，需要有意识地转而接受这种抽象。

1.5  架构师构建架构

要避免将“架构师”工作头衔、构建系统的过程及工程制品（即软件架构）混为一谈

工作头衔：架构师  所有软件开发者都应该理解架构师开发的软件架构，而不仅仅是架构师自己。

过程：构建  团队可以遵循不同的过程，以便开发不同的产品。

工程制品：架构  每个软件系统都有自己的架构，即便拼凑起来的软件也有其架构。

1.6  风险驱动的软件架构

建议使用风险来权衡实施架构的度。

风险驱动模型可以帮助你选择合适的架构技术，从而设计出恰如其分的软件架构。

每个项目都将面临不同的风险，设计软件架构并没有唯一正确的方式：你必须评估每个项目存在的风险。

风险驱动模型只用于设计工作，可将它应用于敏捷过程、瀑布过程及螺旋过程。不同的过程都必须设计软件，区别在于何时开始设计，以及运用何种技术。

1.7  敏捷开发者的架构

恰如其分的架构  架构的风险驱动模型将指导开发者把握架构活动的程度，及时开始编码。

概念模型  有助于推导系统架构与设计的概念模型，相关软件设计与建模技术，以及软件架构的专门知识，都是对敏捷过程的补充与增强。