读书笔记_软件架构设计 程序员向架构师转型必备（第二版）温昱

另读：《一线架构师实践指南》

感慨：大概看这本书对于现在的我来说还太早，经验不足，先成为一个好的程序员吧……以后再回来看这本书

第1章 从程序员到架构师

第2章 解析软件架构概念

Architecture架构，每个人的理解都不同。
分为组成派和决策派。
组成派：软件系统的架构将系统描述为计算组件以及组件之间的交互（The architecture of a software system defines that system in term of computational components and interactions among those components. ）。更多地关注软件，分析软件组成。
决策派：某个软件或计算机系统的架构是该系统的一个或多个结构，每个结构均由软件元素、这些元素的外部可见属性、这些元素之间的关系组成（The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. ）。更关注人，归纳了架构决策的类型。
系统、子系统、框架都可以有架构，只是粒度不同。
架构不仅仅是接口的问题，还有并发、部署、性能、安全等因素需要考虑设计方案，而分层很重要，迭代地细化设计，并且灵活应用设计模式。

第3章 理解架构设计视图

架构设计需要面向：用户、客户、开发人员、管理人员等，为项目相关不同人员而设计。
物理视图+逻辑视图。
使用分而治之和迭代式设计（而非瀑布式）。
经历设计在前，成为架构师在后。
尽量找机会看看别人的设计成果、多体会别人的设计过程、多试着自己来设计设计。

第4章 架构设计过程

程序员向架构师转型难在哪里？难在必须要能开始“试着做起来”，并慢慢积累感觉，进而积累经验。
洞察节奏3个原则：1、看透需求（基础）；2、架构大方向正确（确定正确的概念架构）；3、设计好架构的各个方面（通过多视图方法“细化架构”，通过“架构原型”验证架构）。
看透需求：需求要全（功能需求、质量需求、约束需求），矛盾关系，追溯关系（如追溯系统目标）。
架构大方向正确：概念架构，是策略，如架构模式、集成技术选型。（重要！！！直指系统设计目标的设计思想和重大选择，是关乎任何复杂系统成败的最关键的指向性的设计。对比分析几种可能的概念架构）
设计好架构的各个方面：架构师必须具备“忘却”的能力，避免设计太多具体的技术细节，5视图。
有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别：重大需求；特色需求；高风险需求；据此来决定如何划分顶级子系统，采用什么架构风格和开发技术，集成是否要支持，二次开发是否要支持（1个决定4个选型）。
掌握过程6个步骤：（1）需求分析（2）领域建模（3）确定关键需求（4）概念架构设计（5）细化架构设计（模块+接口）（6）架构验证（对后续工作产生重大影响返工代价很高的任何工作都应该进行验证，包括需求和架构设计方案）。
领域建模：以提炼领域概念，建立领域模型为目的的活动。精髓是“业务决定功能，功能决定模型”。领域建模活动的输入：功能和可扩展性具体要求。

第5章 需求分析

愿景分析：要解决项目、产品或解决方案的起源问题。所谓明确愿景，就是针对系统目标、主要特性、功能范围、成功要素等进行构思并达成一致。（需求分析，得到需求文档）
愿景=业务目标+规范+Feature+上下文图。
《软件需求规格说明书》（Software Requirements Specification, SRS）需求分层次，需求分不同方面。
ADMEMS矩阵（需求层次-需求方面矩阵）
软件质量：运行期质量属性和开发期质量属性。（性能，安全性，易用性，持续可用性，可伸缩性，互操作性，可靠性，鲁棒性，易理解性，可扩展性，可重用性，可测试性，可维护性，可移植性）
约束需求=业务环境因素+使用环境因素+构建环境因素+技术环境因素
需求=功能+质量+约束

第6章 用例与需求

用例技术族：用例图，用力简述（用户故事），用例规约，用例实现（鲁棒图）。

第7章 领域建模

领域模型：就是将领域概念（即领域行话）以可视化的方式抽象成一个或一套模型。是探索问题领域的工具，而已帮助我们探索和提炼问题领域的知识。
就UML而言，领域模型最常采用：类图和状态图。
需求人员视角：促进用户沟通，解决分析瘫痪。
功能决定如何建模，模型决定功能扩展。（要考虑多种情况以及未来可能）
多个项目可能共享某任务。

第8章 确定关键需求

什么决定了架构：用例驱动论，质量决定论，经验决定论。
关键需求决定了架构。
确定关键质量，确定关键功能。
小系统与大系统的分水岭。
拿来主义需要经过对比。

第9章 概念架构设计

概念架构是直指目标的设计思想、重大选择。
概念架构界定系统的高层组件、以及他们之间的关系。概念架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念架构规定了每个组件的非正规的、以及架构图，但不涉及接口细节。
鲁棒图：边界对象，控制对象，实体对象。
1个决定4个选择：决定如何划分顶级子系统，架构风格选型，开发技术选型，二次开发技术选型，集成技术选型。

第10章 细化架构设计

5个视图。15个设计任务。
逻辑架构（模块划分、接口定义、领域模型），开发架构（技术选型、文件划分、编译关系），运行架构（技术选型、控制流划分、同步关系），物理架构（硬件分布、软件部署、方案优化），数据架构（技术选型、存储格式、数据分布）。

第11章 架构验证

不值得验证的架构，就不值得设计。
原型技术分类和用途：水平原型（行为原型）vs垂直原型（结构原型），抛弃原型（探索原型）vs演进原型（同增量开发思想）。
验证架构：原型法和框架法。框架法更适用于产品型开发。测试运行期质量，评审开发期质量。

第12章 粗粒度“功能模块”划分

掌握模块划分技巧，我们分4步进行，涉及，日常涉及工作常用的功能树、分层框架、用例模块、模块化等技巧：（1）粗粒度的“功能模块”划分，应该怎么做（2）如何分层，如何分别封装各种“外部交互”？（3）从用例（需求）到模块划分结构（设计）的具体步骤？（4）水平切分（层）不等于垂直切分（功能模块）不等于通用专用分离。细粒度模块化时，这样综合利用多种模块划分技巧？
借助功能树，划分粗粒度“功能模块”。
从“功能树”到“功能模块”是粗粒度功能模块划分的常用手段。
仅仅是“业务模块划分结构”会带来三大问题：（1）后续研发任务不明确（2）细粒度功能上有重叠（3）代码级重复在所难免。

第13章 如何分层

“学样儿”未必合适，“知其所以然”才是王道。
常见分层：展现层+业务层+数据层，UI层+SI层+PD层+DM层，
分层架构的“封装外部交互”思想；设计分层架构，从上下文图开始。

第14章 用例驱动的模块划分过程

描述需求的序列图vs描述设计的序列图
从用例到类，再到模块。

第15章 模块划分的4步骤方法-运用层、模块、功能模块、用例驱动

封装驱动设计方法EDD：细粒度划分。综合运用分层、分层细化、功能模块、通用模块、通用机制框架化等多种手段，是该方法的特点。步骤：研究需求，粗粒度分层，细粒度划分模块，用例驱动的模块划分结构评审、优化。