《一线架构师实践指南》笔记

第11章 细化架构的故事

 架构先行，因为架构直接关系到具体的软件设计，比如架构对模块影响很大，直接决定了模块的表现形式。

架构设计阶段性原理:至少有概念架构和细化架构两个阶段，我文档中显然是概念架构。

机制是架构的灵魂。

架构多视图原理，多视图原理可以作为文档的思路，把每个视图说明清楚文档也就完成了。

如何用架构相关原理来理解来源软件呢？用多视图原理来理解来源软件，特别是运行架构视图，分析其中的机制算是比较实用的了。

***************************************************************************
第12章 Refined Architecture总论

架构的概念很大很全，所以注定你要采用多个视角来观察分析，以全面理解架构的概念，为架构设计打下基础。所以细化架构设计的王道：多视图法。多视图要保持一致，不能冲突。多视图也体现了思考的角度问题，体现了分而治之的思想。能从几个视图来分析架构这本身也体现了架构设计者的能力，所以多视图分析能力是架构设计的一个必须能力和素质。

多视图到底是哪几个视图？我觉得在架构设计不同阶段，这个应该有着不同的含义，包含着不同的视图。这也体现了架构设计者对视图在架构设计过程中的动态变化的把握能力。

RUP 4+1视图模型

比如SEI 3视图：模块视图，组件-连 接视图（这个其实就是模块间如何通信，把重点放在模块间通信机制上了，也就是重点关注模块间通信），分配视图（这个视图在书上写得比较乱，包括了元素存储 在什么文件，分配给开发小组的软件元素是什么，我觉得正确的认识可以是这样的：分配视图就是模块的组织成层，模块在层上的分配）。

为什么会有RUP 4+1视图和SEI 3视图呢？我觉得原因是，这些视图的划分是基于特定的项目或特定的软件开发过程的，比如针对嵌入式C语言项目的开始和基于Java的电信项目的开发，其视图一定不能相同，充其量只能有些相似而已。为当前的项目定义一个合适的多视图方法是架构设计者的一个基本能力。在写架构文档过程中，也可以按照多视图的角度来组织文件。多视图方法也是业界广泛认同的一种架构设计思路，具体的多视图方法也是种类繁多。

一个视图就是一个思维角度，有角度就有空间。从不同的角度规划分割与交互。

思考的最大障碍在于混乱，抓住每个视图的思维立足点。

架构=组件+交互，是业界的基本认识，架构的每个视图都有自己关心的组件。

 *******************************************************************************

第13章 逻辑架构

架构最重要的一点就是把处理的大问题分解为便于管理的小问题。

划分子系统是架构设计过程中的必经之路，它有三个策略可以使用：分层的细化，分区（分模块）的引入，机制的提取。划分子系统的提出将架构设计套路化了，有章可循了，易于实现架构设计的标准化。架构设计三板斧：分层的细化à分区（分模块）的引入à机制的提取。

 

分层细化只是架构设计的第一步，根据多视图原理，分层是从逻辑视图入手的，那么从其它视图比如开发视图，运行视图入手，分层的细化显然会对这些视图产生影响。最典型的是分层会对开发视图也就是文件结构产生影响。

 

分层和分区（分模块）是比较容易的，架构设计的灵魂是机制的提取。机制的目的在于协作模块和一系列对象。机制直接说比较抽象，从逻辑视图角度来讲，机制就是特殊的机制模块，它和功能模块相对应，为其它的功能模块提供服务，从运行架视图来说机制是和进程线程同级的运行架构视图基本单位。

 

功能永远是一个链条，将链条适当切分就形成了模块，切分方法的不同，则产生不同的模块，这也体现了模块设计的精妙所在。通用做法是通过职责划分来分离关注点（关注点分离也是有特殊技巧的，这个在冒号课堂中再细说吧）。比如点亮LED灯，这是个功能链条，简单切分可以是：底层端口驱动，中间层数据表示，上层的LED灯相关。你可以这三个基本的切分中间加入小型的过滤模块，比如有中间层和上层间添加一个数据路由和统计模块，实现一些特殊的功能。

总 结一下：功能（包括一般功能和机制功能）永远是链条，链条要切换，分层是对链接的天然切分形式。分层切分之外，可以通过在链条添加小型过滤模块实现特殊功 能。反之，任何一个模块都要放在功能链条中来思考认识，孤立地分析一个模块是大忌，也就是说，模块永远处于和其它模块动态交流之中。序列图是功能链条的最直接体现。平时所说的设计模式也是属于机制功能部分。

模块=功能模块+机制模块。

常见的机制包括：脚本自动生成代码，信号机制，消息机制，事件机制（系统级事件，模块级事件），回调函数，Hook。

逻辑架构设计可以使用：包-接口图来表示，这个用于文档中比较合适。

设计模式一般多用于类级别，在子系统设计中也可以使用设计模式，只是其基本作用单位是灰盒包图。所谓的灰盒包图其实就是功能包图，就是各个功能的简单临时组合，不重各个功能的实际物理分布，只是为了表现设计模式而临时放在一起。

**********************************************************************

第14章节 物理架构 运行架构 开发架构

物理架构视图可以理解为单片机资源分配。

开发架构算是最接地气的架构了，他直接关系到文件夹结构，关系到文件布局，可以认为是文件分布。

 

非功能性需求，比如重用性，效率等，要时时考虑。要持续不断的考虑非功能需求。

**********************************************************************

第16章节 困扰已久的非功能性需求

定义架构设计的基本公式和原理，这样便于理解记忆，便于实施。

需求分类原理:需求分为功能性需求和非功能性需求。

需求网络化原理:需求不是孤立的，需求会组织成需求网络，也会组织成需求链条，网络是链条联合的结果。

需求推导原理:需求可以互相推导，需求链条就是推导链条，推导链条之外没有需求存在。