一线架构师实践指南读书笔记

重大风险：功能 质量 约束
高层切分：借助鲁棒图，初步识别功能别后的职责，就可以规划高层切分的具体方式
分析和综合是思维方向相反的过程。一般是先分析后综合，没有分析就不能综合，没有综合，也只是片面的分析
通过系统切分，虽然无法降低复杂性，当可以控制复杂性

分层式概念架构：逻辑层 物理层 通用性分 技术堆叠
概念架构：系统切分 技术选择 权衡策略
考虑非功能性需求：目标 场景 决策
质疑驱动架构
方案和架构的区别：方案包含一定的架构内容，方案涉的架构基本在概念一级 架构设计工作还远远未完成
细化结构和概念架构的区别：接口 子系统 交互机制
概念架构(概念及方案) 细化架构(规约及方案)
细化架构属于架构设计不是详细设计

概念 细化 实现
概念架构第一阶段  逻辑架构和物理架构是同一阶段

架构设计依赖：
明确的业务需求-愿景
全面的用户需求-用例图
典型的行为需求-用例规约 (此时架构与需求并行)


4大环境：
业务环境，使用环境，构建环境，技术环境


3大需求：
业务需求(项目视图和范围文档)
用户需求(用例文档)
功能需求(系统需求)

多重架构视图必不可少，因为不同涉众(用户，客户，开发人员，测试人员，维护人员，内部操作人员，其它人员)需要从各自的角度理解和使用架构。
架构设计的内容和决策多，超过了人脑一蹴而就的能力范围，因此采用不同的世界分别设计，对软件架构的理解交流提供了方便
数据量大+计算量大
物理结构主要着重考虑运行软件的计算机 网络 硬件设施情况，还包括软件的部署以及运行时的配置情况，还包括软件系统和硬件系统在内的这个it系统是如何相互影响的


物理架构：1，硬件选择 物理拓扑  2，软件到硬件映射 3，方案优化
降低开销 避免争用 来实现高性能和高可伸缩性


物理架构思维框架：目标层(XX性)，思维层(XX开销，xx争用)，结果层(软件单元, 数据单元, 物理节点, 网络)


运行架构：如果系统中没有引入并行处理或者并发处理，并且系统也没有基于sdk，api等基础软件进行定制开发，那就不许要运行架构


运行架构包括：1，控制流(进程线程，中断的服务)2，控制流组织(系统启动停机 控制流通信 加锁或者同步)


确定引入控制流的几点建议：为了实现节点之间的通信，通常的做法是引入一条控制流来专门负责，物理架构中每个节点至少有一个控制流，节点是具有主动行为的设备，并为其引入专门的控制流，来自用户或者外部系统的并发访问，常需要后端服务支持多控制流。在需求一级描述的并发或者并行的也需要引入控制流


一单系统中不止一条控制流，则需要附加工作量(创建 销毁 建立共享内存 消息)等不同工作量直接的通信机制


控制流：是再一个处理机上顺序执行的系列动作。控制流图显示了系统中不同控制流之间的关系，控制流的起点是主动单元，它会调用被动单元，如此层层调用，就形成了一个控制流。明确了系统中所有的主动单元，就抓住了每个控制流的源头，从而可以把并发执行的所有控制流程理清楚。


运行架构设计工作只要把握住控制流图，就能提纲挈领的开着其它设计工作


控制流的常用手段：进程 线程 中断的服务 

------------------------------------------------
开发架构：1，逻辑单元映射为程序单元(自主编写源程序，可重用的库和框架，其它方式:shell 平台下的配置文件)2，开发技术选项(语言，工具)3，程序单元间的关系(project划分，project目录，编


译依赖关系)此project是指ide下的


为何开发人员重复修改bug：架构师 1，重交付 轻维护2，重视小粒度重用，忽视大粒度重用
重用价值=重用次数*单次价值
------------------------------------------------
数据库错误和架构选择错误是致命的错误


确定数据分布方案是数据架构的难点。


数据分布的策略：独立(应用不同，schema不同) 集中(集中存储分布访问，应用不同，schema相同) 分区(相同程序不同实例，相同数据模型不同数据) 复制(实时或者快照) 子集(保寸部分数据，本地化


固定的数据) 重组(业务决定功能，功能决定模型。技术etl) 


数据分布策略应用的原则：1，把握系统特点，确定分布策略(合适原则)2，不同分布 策略可以综合使用(综合原则)3,从对吗 好吗两方面优化(优化原则)

----------------------------------------------------------
pre架构阶段就要1，考虑系统重点支持的关键质量目标 2，关键指标有没冲突，并制定权衡取舍策略


功能需求 质量属性 约束 共同决定了结构
基于：业务背景 系统规模 技术趋势 开发团队现状等情况，对需求进行理性的有针对的权衡取舍补充。
软件需求=功能需求+质量属性+约束


确定关键质量：1，分类合适 +必要扩充 (提供基础)2，考虑多发涉众 (必要扩充)3，检查性思维4，识别矛盾划定优先级 (折冲依据)5，严格程度符合领域和规模特点(定量参考)


强大的api支持，便于二次开发
基于spi(服务编程接口)的可扩展设计


概念架构师售前的必修课


架构设计贵在有针对性，重大需求 高风险需求 特色需求，给出高层次的解决方案。备选架构经常是概念一级的
概念架构为投标 售前 市场宣传 等工作提供强有力的支持。所以概念架构师市场和售前的必修课


基于关键功能进行初步设计，综合初步设计进行高层切割，考虑非功能需求做出相应决策
四拍决策者：决策时拍脑袋就这么定了 指挥时拍胸脯保证没问题 失误时拍大腿我怎么没想到 追查时拍屁股老子不干了


软件质量很飘，如何使很飘的非功能需求稳定下来1，需求决定架构，架构设计的结果已经属于解决方案的范畴2，架构设计是从需求域向设计域的过度过程3，很飘意味着非功能需求导出设计决策跨度太大了4，需要一种过度技术承上启下，它就是场景技术


以场景为跳板的非功能目标设计思维 目标 场景 决策 


场景的5要素：影响来源，如何影响 受影响对象 问题或价值 所处环境


场景是基础技术 用例是应用技术。
通过场景化增强非功能需求的验证性。