Architectural Design Method has been Extended to Method System
Pre—Architecture阶段使命：全面理解需求，从而把握需求特点，进而确定架构设计驱动力 （ADMEMS矩阵，p27）
Conceptual Architecture阶段：重大需求塑造做概念架构
没有风险的软件早就开发完了！
错的一半是金，败的一半是贝
第3章 Pre—Architecture总论：
1. 工作目标：
理解需求，建立需求大局观，确定架构设计方向
2. 关键需求决定架构，其余需求验证架构
3. 任何需求都可以定位于业务级需求、用户级需求、开发级需求这3个层次的某一层，同时也比属于功能、质量、约束这3类需求中的一类。
4. 可以开始架构设计的3个基本条件：
明确的业务需求（愿景）、全面的用户需求（范围）、典型的行为需求
5. 实践要领：
不同需求，影响架构的原理不同（p45）
关键需求决定架构：功能需求做减法，质量属性需求做减法，约束性需求做加法（p48）
6. Pre-architecture阶段4个步骤：
需求结构化、分析约束影响、确定关键质量、确定关键功能
第4章 需求结构化与分析约束影响
1. ADMEMS矩阵（需求层次-需求方面矩阵，p52）3个层次3个角度，理清需求结构大局：
业务级需求：甲方要达到的业务目标、预期投资、工期要求，以及符合哪些标准、对哪些遗留系统进行整合等约束条件？
用户级需求：用户使用系统来辅导完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维修期间有何质量考虑？开发团队的那些情况会反过来影响架构？
功能需求：更多体现各级直接目标要求
质量属性：运行期质量 + 开发期质量
约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素
2. 4类约束（在ADMEMS矩阵中的位置，p54）：
业务环境：上线时间要求、预算限制、集成需要、业务领域、业务规则、业务限制、相关法律法规、专利限制
使用环境：用户阶层、年龄段、编号、是否遍及多个国家、使用场所是否有电磁干扰、车船移动
构建环境：开发团队技术水平、磨合程度、分布、开发管理、源码保密等
技术环境：当前技术环境（技术平台、中间件、编程语言等的流行度、认同度、优缺点等）
3. 约束是架构设计要解决的问题的上下文（软件需求=功能需求+质量属性+约束），图解p56
4. ADMEMS矩阵方法应用法则：
推导法则：从上到下，从右到左
查漏法则：重点是质量属性遗漏
第5章 确定关键质量与关键功能
1. 在需求结构化的基础上，确定关键质量着重完成的2项任务:
根据系统所在的领域特点及系统规模等因素，确定架构设计重点支持哪些质量属性（如重点支持高性能、可扩展性等）
分析质量属性之间的制约关系，第一时间制定权衡折衷的具体策略（如明确高性能是第一位的，可扩展性与高性能相矛盾时应照顾高性能要求，是否引入支持可扩展系能的设计需要经架构组评审）
2. 确定关键质量的5大原则（整体思路图p65）：
分类合适 + 必要扩充
考虑多方涉众
检查性思维
识别矛盾 + 划分优先级
严格程度符合领域与规模特点
3. 确定关键功能的4条规则：
核心功能：业务层接口要反映的功能
必做功能：文档”项目愿景的解决方案“中主要特征应作为备选项、支持”运营“的功能
高风险功能：需要将风险高的功能选入关键功能子集
独特功能：覆盖前3类功能没有涉及到的职责
（注意，关键功能子集并不存在标准答案，关键功能所占比例应灵活确定：功能少的系统比例高些，功能多的系统比例少些）
第7章 概念设计总论
1. 概念架构是大型系统架构设计成败的关键
2. 架构 = 组件 + 交互，机构设计的驱动力 = 功能 + 质量 + 约束
3. 概念架构设计3个步骤：
初步设计、高层分隔、考虑非功能需求
第8章 初步设计
1. 初步设计并总是必须的--架构师只有在设计复杂系统时才需要它
2. 初步设计的目标简单而明确：发现职责！
3. 鲁棒图3元素（与MVC区别p94）：
边界对象
控制对象
实体对象
4. 鲁棒图的作用：
初步设计
检查用例规约是否正确和完善
5. 需求分析、系统分析、初步设计：
需求分析 != 系统分析， 系统分析 约等于 初步设计
用”做什么“和”怎么做“来区分分析与设计，并不全面（系统分析实际上已经包含了部分设计）
需求捕获、需求分析，以及系统分析之间的关系见p97
6. 鲁棒图建模10条经验：
详细见p98
鲁棒图建模规则：
参与者只能与边界对象交谈；
边界对象只能与控制对象和参与者交谈
实体对象只能与控制对象交谈
控制对象既能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈
鲁棒图建立技巧：
发现鲁棒图3中元素的思维方式间p99图8-9
增量建模
7. 明确几点：
初步设计的目标是发现职责，为高层切分奠定基础
初步设计不是必须的，但当待设计系统对架构师而言并无太多直接经验时，则强烈建议进行初步设计
基于关键功能（而不是所有功能），借住鲁棒图（而不是序列图）进行初步设计
第9章 高层分割
1. 2中套路：
切系统为系统
切系统为子系统
2. Tier & Layer：逻辑和物理
第10章 考虑非功能需求
第11章 细化架构的故事
1. 架构师各项具体工作p130，图11-2
第12章 Refined Architecture总论
1. 概念设计 -> 逻辑设计 + 物理设计 （逻辑设计和物理设计是2个并行阶段！）
2. 有角度就有空间，每个视图对应一组关注点，p139图12-7
第13章 逻辑架构
1. 对于大部门团队来说，为了快速迭代，应该：做一个高级的广度设计，然后马上转到深度优先的底层设计和实现上去
2. 划分子系统的3种必用策略：
分层（Layer细化）
分区（分区是一种单元，它位于某个层的内部，其粒度比层小）
机制的提取（机制：预先定义好的、能够完成预期目标的、基于抽象角色的协作方式，包含：协作关系+协作流程）
3. 划分子系统的4个通用设计原则：
职责不同的单元划归不同子系统
通用性不同的单元划归不同子系统
需要不同开发技能的单元划归不同子系统
兼顾工作量的相对均衡，进一步划分太大的子系统
4. 协作决定接口（不是：我的接口我做主）
5. 质疑驱动的逻辑架构设计：质疑驱动、结构设计和行为设计相分离
第14章 物理架构、运行架构、开发架构
1. 物理架构设计工作内容：
硬件选择与物理拓扑
软件到硬件的映射关系
方案的优化
2. 运行架构设计工作内容：
确定引入哪些控制流（进程、线程、终端服务程序）
确定每条控制流的任务
控制流的创建、销毁、通信机制等
控制流之间的同步关系、资源争用时的加锁机制
3. 开发架构设计的工作内容：
将逻辑职责映射为程序单元（可重用的库、框架，要自主编写的源程序，shell脚本、平台支持下的配置文件等）
开发技术选型（语言、工具）
程序单元间关系：project划分、project目录结构、编译依赖关系
第15章 数据架构的难点：数据分布
1. 数据分布的6种策略：
独立Schema（Application不同，Schema不同）：可减少系统间无谓的相互影响，避免人为地将问题复杂化
集中（集中存储、分布访问）：
分区（相同的应用程序、不同的应用程序部署实例；系统的数据模型、不同的数据值）：水平分区（地域）应用较多、垂直分区（应用程序）应用较少
复制（通过实时或快照方式保持多个数据副本之间的数据一致）
子集（某节点因功能或非功能考虑而复制全体数据的一个相对固定的子集）：减少数据传递开销、节省存储成本
重组（不同数据节点因要支持的功能不同，而以不同Schema复制数据）：如数据从生产系统到BI系统
6种策略二维比较图见p179图15-8
2. 6种数据分布策略的3条应用原则：
把握系统特点，确定分布策略（合适原则）
不同分布策略，可以综合运用（综合原则）
从对吗、好吗两方面进行评估优化（优化原则）
第18章 目标-场景-决策表
1. 场景5要素：
影响来源、如何影响、受影响对象、问题或价值、所处环境
