重大风险：功能 质量 约束
高层切分：借助鲁棒图，初步识别功能别后的职责，就可以规划高层切分的具体方式
分析和综合是思维方向相反的过程。一般是先分析后综合，没有分析就不能综合，没有综合，也只是片面的分析
通过系统切分，虽然无法降低复杂性，当可以控制复杂性
分层式概念架构：逻辑层 物理层 通用性分 技术堆叠
概念架构：系统切分 技术选择 权衡策略
考虑非功能性需求：目标 场景 决策
质疑驱动架构
方案和架构的区别：方案包含一定的架构内容，方案涉的架构基本在概念一级 架构设计工作还远远未完成
细化结构和概念架构的区别：接口 子系统 交互机制
概念架构(概念及方案) 细化架构(规约及方案)
细化架构属于架构设计不是详细设计
概念 细化 实现
概念架构第一阶段 逻辑架构和物理架构是同一阶段
架构设计依赖：
明确的业务需求-愿景
全面的用户需求-用例图
典型的行为需求-用例规约 (此时架构与需求并行)
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要素：影响来源，如何影响 受影响对象 问题或价值 所处环境
场景是基础技术 用例是应用技术。
通过场景化增强非功能需求的验证性。