软件系统架构

鲁然斯基等编著的《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》是软件系统架构领域的开创性著作，是两位拥有数十年软件行业工作经验的架构师工作经验的结晶，围绕利益相关者、视点和视角三大主题，创新性地提出了如何用架构视点和架构视图的方法来定义软件架构，如何用架构视角的方法来确保软件质量，以及如何用架构视点和架构视角的方法与利益相关者合作，具有里程碑意义。《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》还展示了一种实用的、经过验证的框架，你可以应用它来处理架构定义过程，并应对创建软件架构工作所带来的挑战。 《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》分为五个部分，共30章。第一部分（第1～5章）阐释利益相关者、架构描述、视点、视图和视角等基本概念，并描述软件架构师的角色；第二部分（第6～14章）描述作为架构师所要从事...

(展开全部)

鲁然斯基等编著的《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》是软件系统架构领域的开创性著作，是两位拥有数十年软件行业工作经验的架构师工作经验的结晶，围绕利益相关者、视点和视角三大主题，创新性地提出了如何用架构视点和架构视图的方法来定义软件架构，如何用架构视角的方法来确保软件质量，以及如何用架构视点和架构视角的方法与利益相关者合作，具有里程碑意义。《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》还展示了一种实用的、经过验证的框架，你可以应用它来处理架构定义过程，并应对创建软件架构工作所带来的挑战。 《软件系统架构(使用视点和视角与利益相关者合作原书第2版)》分为五个部分，共30章。第一部分（第1～5章）阐释利益相关者、架构描述、视点、视图和视角等基本概念，并描述软件架构师的角色；第二部分（第6～14章）描述作为架构师所要从事的重要活动，如协商项目的范围、识别并管理利益相关者、使用场景和模式、创建模型以及为架构创建文档并对其加以验证等；第三部分（第15～23章）集合了在创建架构描述时最重要的七种视点：情境、功能、信息、并发、开发、部署和运维视点；第四部分（第24～29章）集合了对于信息系统最重要的视角，包括安全性、性能和可伸缩性、可用性和适应性、演进、位置、开发资源、国际化等；第五部分（第30章）把这些概念融合在一起，并阐释了如何把这些理论应用到实践中。

海报：

Nick Rozansh，资深软件架构师，拥有30余年软件行业工作经验。他在企业应用程序集成、程序包实现、关系型数据库、数据复制和面向对象的软件开发等领域有自己独到的见解，积累颇丰。他在包括金融、零售、制造和行政等多个领域担任重要的角色，曾任职于多家大型系统集成公司，包括Logica、Capgemini和Sybase，以及玛莎百货和Barclays全球投资公司，目前是英国一家大型银行前端IT部门的主要负责人。他曾在剑桥大学和曼彻斯特大学求学，是英国计算机学会的注册工程师和注册会员。他还是一位经验丰富的技术讲师和通过认证的内部项目审计员。

Eoin Woods，资深软件架构师，拥有近20年软件行业工作经验。他对软件架构、分布式系统、计算机安全和数据管理等技术都有深入研究。曾在多家技术公司、顾问公司和金融服务公司任职，目前是欧洲一家大型投资银行的首席软件...

(展开全部)

Nick Rozansh，资深软件架构师，拥有30余年软件行业工作经验。他在企业应用程序集成、程序包实现、关系型数据库、数据复制和面向对象的软件开发等领域有自己独到的见解，积累颇丰。他在包括金融、零售、制造和行政等多个领域担任重要的角色，曾任职于多家大型系统集成公司，包括Logica、Capgemini和Sybase，以及玛莎百货和Barclays全球投资公司，目前是英国一家大型银行前端IT部门的主要负责人。他曾在剑桥大学和曼彻斯特大学求学，是英国计算机学会的注册工程师和注册会员。他还是一位经验丰富的技术讲师和通过认证的内部项目审计员。

Eoin Woods，资深软件架构师，拥有近20年软件行业工作经验。他对软件架构、分布式系统、计算机安全和数据管理等技术都有深入研究。曾在多家技术公司、顾问公司和金融服务公司任职，目前是欧洲一家大型投资银行的首席软件架构师，负责该公司大量关键系统的架构和设计。他拥有布鲁塞尔大学软件工程学士学位和曼彻斯特大学软件工程硕士学位。他还是工程技术协会的注册会员，并且是英国计算机学会的注册工程师和注册会员。

侯伯薇，资深软件开发工程师、系统工程师和系统分析师，拥有10余年软件行业从业经验。现就职于中荷人寿保险有限公司，担任高级系统分析师。致力于技术与业务的融合，让开发的程序能够真正提高业务人员的工作效率。InfoQ中文站翻译团队主编，热衷于通过翻译和演讲的方式与广大程序员分享和交流，曾翻译过多本技术书籍和几百篇技术短文，并多次在Scrumgathering、QClub、敏捷之旅等活动上发表技术演讲。

译者序
前言
第1版前言
第1章 简介 1
1.1 利益相关者、视点和视角 1
1.2 本书结构 4
· · · · · · (更多)

译者序
前言
第1版前言
第1章 简介 1
1.1 利益相关者、视点和视角 1
1.2 本书结构 4
1.3 谁应该阅读本书 5
1.4 本书约定 5
第一部分 架构的基本原则
第2章 软件架构概念 8
2.1 软件架构 8
2.1.1 系统元素和关系 8
2.1.2 基本系统属性 9
2.1.3 设计和发展的原则 10
2.1.4 系统属性和内部组织形式 10
2.1.5 软件架构的重要性 13
2.2 架构元素 13
2.3 利益相关者 14
2.3.1 个人、团队或组织 14
.2.3.2 兴趣和关注点 15
2.3.3 利益相关者的重要性 16
2.4 架构描述 16
2.5 核心概念之间的关系 17
2.6 小结 18
2.7 延伸阅读 19
第3章 视点和视图 20
3.1 架构视图 22
3.2 视点 23
3.3 核心概念之间的关系 24
3.4 使用视点和视图的好处 24
3.5 视点缺陷 25
3.6 视点目录 25
3.7 小结 27
3.8 延伸阅读 28
第4章 架构视角 29
4.1 质量属性 29
4.2 架构视角 30
4.3 向视图应用视角 33
4.4 应用视角的结果 34
4.4.1 深入的观点 34
4.4.2 提升 35
4.4.3 精品内容 35
4.5 核心概念之间的关系 35
4.6 使用视角的好处 36
4.7 视角的缺陷 37
4.8 视角与视点对比 37
4.9 视角种类 38
4.10 小结 39
4.11 延伸阅读 39
第5章 软件架构师的角色 41
5.1 架构定义过程 41
5.1.1 架构定义不仅是设计 42
5.1.2 需求分析和架构定义之间的区别 43
5.1.3 架构定义和设计之间的区别 43
5.2 架构师的角色 44
5.3 核心概念之间的相互关系 46
5.4 架构专门化 47
5.5 组织情境 47
5.5.1 业务分析师 47
5.5.2 项目经理 47
5.5.3 设计主管 48
5.5.4 技术专家 49
5.5.5 开发者 49
5.6 架构师的技能 49
5.7 架构师的责任 50
5.8 小结 51
5.9 延伸阅读 51
第二部分 软件架构过程
第6章 软件架构过程简介 54
第7章 架构定义过程 55
7.1 指导原则 55
7.2 过程产出物 56
7.3 过程情境 56
7.4 支持活动 57
7.5 架构定义活动 60
7.6 过程完成标准 62
7.7 软件开发生命周期中的架构定义 64
7.7.1 瀑布式方法 64
7.7.2 迭代方法 65
7.7.3 敏捷方法 65
7.8 小结 66
7.9 延伸阅读 67
第8章 关注点、原则和决定 68
8.1 专注于问题的关注点 70
8.1.1 业务策略 70
8.1.2 业务目标和驱动力 70
8.1.3 系统范围和需求 71
8.1.4 业务标准和政策 72
8.2 专注于解决方案的关注点 72
8.2.1 IT策略 72
8.2.2 技术目标和驱动力 72
8.2.3 技术标准和政策 73
8.3 其他现实世界中的约束 73
8.4 什么决定了好的关注点 75
8.5 架构原则 75
8.5.1 什么造就了好的原则 78
8.5.2 定义自己的原则 78
8.6 架构决定 79
8.7 使用原则关联关注点和决定 81
8.8 检查列表 82
8.9 小结 83
8.10 延伸阅读 83
第9章 确定并引入利益相关者 84
9.1 利益相关者的选择 84
9.2 利益相关者的类别 85
9.2.1 出资方 86
9.2.2 评估者 86
9.2.3 沟通者 86
9.2.4 开发人员 87
9.2.5 维护人员 87
9.2.6 生产工程师 87
9.2.7 供应商 87
9.2.8 支持人员 87
9.2.9 系统管理员 88
9.2.10 测试人员 88
9.2.11 用户 88
9.3 示例 88
9.3.1 非专门设计的部署项目 88
9.3.2 软件产品开发项目 89
9.3.3 合作开发 89
9.4 代理利益相关者 90
9.5 利益相关者组 90
9.6 利益相关者的责任 90
9.7 检查列表 91
9.8 小结 91
9.9 延伸阅读 92
第10章 识别并使用场景 93
10.1 场景类型 93
10.2 使用场景 94
10.3 识别场景并排定优先级 95
10.4 捕获场景 96
10.5 什么造就了好场景 98
10.6 应用场景 98
10.6.1 纸质模型 98
10.6.2 走查 99
10.6.3 模拟 100
10.6.4 原型实现的测试 100
10.6.5 完整规模真实测试 100
10.7 有效使用场景 100
10.7.1 识别一系列重点场景 101
10.7.2 使用清晰的场景 101
10.7.3 尽早使用场景 101
10.7.4 包含对系统质量场景的使用 101
10.7.5 包含对故障场景的使用 101
10.7.6 让利益相关者紧密参与 101
10.8 检查列表 102
10.9 小结 102
10.10 延伸阅读 103
第11章 使用样式和模式 104
11.1 设计模式介绍 104
11.2 样式、模式和惯用法 105
11.2.1 架构样式 106
11.2.2 软件设计模式 106
11.2.3 语言惯用法 106
11.2.4 使用样式、模式和惯用法 107
11.3 模式和架构策略 107
11.4 架构样式的例子 108
11.5 使用架构样式的好处 110
11.6 样式和架构描述 111
11.7 应用设计模式和语言惯用法 111
11.8 检查列表 113
11.9 小结 113
11.10 延伸阅读 113
第12章 创建架构模型 115
12.1 模型为什么重要 115
12.2 模型的类型 117
12.2.1 定性模型 117
12.2.2 定量模型 118
12.2.3 示意图 119
12.3 建模语言 119
12.3.1 架构描述语言 119
12.3.2 统一建模语言 120
12.3.3 可执行的领域专用语言 121
12.3.4 其他建模语言 121
12.4 创建有效模型的准则 121
12.4.1 有目的地建模 121
12.4.2 应对受众 122
12.4.3 仔细、准确地抽象 122
12.4.4 根据风险确定工作重点 123
12.4.5 选择描述性的名称 123
12.4.6 定义你的术语 123
12.4.7 以简单为目标 124
12.4.8 使用已定义的标记法 124
12.4.9 了解暗示的语义 124
12.4.10 验证模型 125
12.4.11 保持模型的活力 125
12.5 和敏捷团队一起建模 125
12.6 检查列表 126
12.7 小结 127
12.8 延伸阅读 127
第13章 创建架构描述 128
13.1 有效架构描述的属性 129
13.1.1 正确 129
13.1.2 充分 129
13.1.3 及时 130
13.1.4 简洁 131
13.1.5 清晰 131
13.1.6 最新 132
13.1.7 精确 133
13.2 词汇表 134
13.3 ISO标准 134
13.4 架构描述的内容 135
13.4.1 文档控制 135
13.4.2 内容表 135
13.4.3 介绍和管理纲要 135
13.4.4 利益相关者 136
13.4.5 通用架构原则 136
13.4.6 架构设计决定 136
13.4.7 视点 136
13.4.8 视图 136
13.4.9 质量属性摘要 137
13.4.10 重要的方案 137
13.4.11 亟待解决的问题 137
13.4.12 附录 138
13.5 展现架构描述 138
13.6 检查列表 139
13.7 小结 140
13.8 延伸阅读 140
第14章 评估架构 141
14.1 为什么要评估架构 141
14.2 评估技术 142
14.2.1 演讲 142
14.2.2 正式评审和结构化的走查 143
14.2.3 通过使用场景来评估 144
14.2.4 原型和概念验证系统 145
14.2.5 骨架系统 146
14.3 基于场景的评估方法 146
14.3.1 以架构为中心的活动 147
14.3.2 以利益相关者为中心的活动 149
14.4 在软件生命周期内评估 150
14.5 验证现存系统的架构 151
14.6 记录评估结果 153
14.7 选择评估方法 154
14.8 检查列表 154
14.9 小结 155
14.10 延伸阅读 155
第三部分 视点类型
第15章 视点类型简介 158
第16章 情境视点 160
16.1 关注点 161
16.1.1 系统范围和责任 161
16.1.2 外部实体和服务以及所用数据的标识 161
16.1.3 外部实体的本质和特征 162
16.1.4 外部接口的标识和职责 162
16.1.5 外部接口的本质和特征 163
16.1.6 其他外部依赖关系 163
16.1.7 对系统环境的影响 164
16.1.8 总体完成度、一致性和连贯性 164
16.1.9 利益相关者的关注点 165
16.2 模型 165
16.2.1 情境模型 165
16.2.2 交互场景 169
16.3 问题和缺陷 169
16.3.1 遗漏或者错误的外部实体 169
16.3.2 遗漏隐藏的依赖关系 169
16.3.3 松散或不精确的接口描述 170
16.3.4 详细程度不合适 170
16.3.5 范围蔓延 170
16.3.6 隐藏或假设的情境和范围 171
16.3.7 过于复杂的交互 171
16.3.8 过度使用术语 171
16.4 检查列表 172
16.5 延伸阅读 172
第17章 功能视点 173
17.1 关注点 173
17.1.1 功能能力 173
17.1.2 外部接口 174
17.1.3 内部结构 174
17.1.4 功能设计哲学 174
17.1.5 利益相关者的关注点 175
17.2 模型 176
17.3 问题和缺陷 184
17.3.1 设计很差的接口 184
17.3.2 难以理解的职责 184
17.3.3 基础架构作为功能性元素 184
17.3.4 过载的视图 185
17.3.5 没有元素定义的图 186
17.3.6 难以调节多位利益相关者的需求 186
17.3.7 错误的详细程度 187
17.3.8 “神元素” 187
17.3.9 过多依赖关系 188
17.4 检查列表 188
17.5 延伸阅读 188
第18章 信息视点 190
18.1 关注点 191
18.1.1 信息结构和内容 191
18.1.2 信息目的和用途 191
18.1.3 信息所有权 192
18.1.4 企业拥有的信息 193
18.1.5 标识符和映射关系 194
18.1.6 信息语义的易变性 195
18.1.7 信息存储模型 196
18.1.8 信息流 197
18.1.9 信息一致性 198
18.1.10 信息质量 199
18.1.11 及时性、延迟和寿命 200
18.1.12 归档和保留信息 201
18.1.13 利益相关者的关注点 201
18.2 模型 202
18.2.1 静态信息结构模型 202
18.2.2 信息流模型 204
18.2.3 信息生命周期模型 206
18.2.4 其他类型的信息模型 207
18.3 问题和陷阱 209
18.3.1 数据展现不兼容 209
18.3.2 不可避免的多个更新器 210
18.3.3 键值匹配缺陷 211
18.3.4 接口复杂 211
18.3.5 过载的中心数据库 212
18.3.6 不一致的分布式数据库 213
18.3.7 信息质量很差 213
18.3.8 信息延迟过大 213
18.3.9 容量不足 214
18.4 检查列表 214
18.5 延伸阅读 215
第19章 并发视点 216
19.1 关注点 217
19.1.1 任务结构 217
19.1.2 功能元素与任务的映射关系 218
19.1.3 进程间通信 218
19.1.4 状态管理 218
19.1.5 同步和整合 218
19.1.6 支持可伸缩性 219
19.1.7 启动和关闭 219
19.1.8 任务故障 219
19.1.9 重入 219
19.1.10 利益相关者的关注点 220
19.2 模型 220
19.2.1 系统级别的并发模型 220
19.2.2 状态模型 225
19.3 问题和缺陷 228
19.3.1 对错误的并发建模 228
19.3.2 错误地对并发建模 228
19.3.3 过度复杂 229
19.3.4 资源竞争 229
19.3.5 死锁 230
19.3.6 竞争条件 230
19.4 检查列表 230
19.5 延伸阅读 231
第20章 开发视点 232
20.1 关注点 232
20.1.1 模块组织 232
20.1.2 通用处理 233
20.1.3 设计的标准化 233
20.1.4 测试的标准化 233
20.1.5 测试辅助 233
20.1.6 代码行组织 233
20.1.7 利益相关者的关注点 233
20.2 模型 234
20.2.1 模块结构模型 234
20.2.2 通用设计模型 235
20.2.3 代码行模型 238
20.3 问题和缺陷 239
20.3.1 过多细节 239
20.3.2 过载的架构描述 239
20.3.3 不平均的重点 240
20.3.4 缺少开发者的关注 240
20.3.5 精度不足 240
20.3.6 特定环境的问题 240
20.4 检查列表 241
20.5 延伸阅读 241
第21章 部署视点 243
21.1 关注点 243
21.1.1 所需的运行时平台 243
21.1.2 硬件或者托管平台所需的规格和品质 244
21.1.3 第三方软件需求 244
21.1.4 技术兼容性 244
21.1.5 网络需求 245
21.1.6 所需的网络能力 245
21.1.7 物理约束 245
21.1.8 利益相关者的关注点 245
21.2 模型 246
21.2.1 运行时平台模型 246
21.2.2 网络模型 249
21.2.3 技术依赖关系模型 250
21.2.4 模型之间的关系 251
21.3 问题和缺陷 252
21.3.1 不清晰或者不精确的依赖关系 252
21.3.2 未经验证的技术 253
21.3.3 不合适或者遗漏的服务级别 协议 253
21.3.4 缺少专家的技术知识 253
21.3.5 未能及时考虑部署环境 254
21.3.6 忽略站点间的复杂性 254
21.3.7 提供的净空不合适 254
21.3.8 未指定灾难恢复环境 255
21.4 检查列表 255
21.5 延伸阅读 256
第22章 运维视点 257
22.1 关注点 257
22.1.1 安装和升级 257
22.1.2 功能迁移 258
22.1.3 数据迁移 258
22.1.4 运维监控和控制 259
22.1.5 警告 260
22.1.6 配置管理 260
22.1.7 性能监控 260
22.1.8 支持 261
22.1.9 备份和还原 261
22.1.10 第三方环境中的运维 262
22.1.11 利益相关者的关注点 262
22.2 模型 263
22.2.1 安装模型 263
22.2.2 迁移模型 265
22.2.3 配置管理模型 265
22.2.4 管理模型 267
22.2.5 支持模型 270
22.3 问题和缺陷 273
22.3.1 缺少运维人员的参与 273
22.3.2 缺少撤销计划 273
22.3.3 缺少迁移计划 273
22.3.4 不充分的迁移窗口 274
22.3.5 遗漏管理工具 274
22.3.6 生产环境的约束 274
22.3.7 缺少到生产环境中的整合 275
22.3.8 不充分的备份模型 275
22.3.9 不合适的警告 275
22.4 检查列表 276
22.5 延伸阅读 276
第23章 保持视图一致性 277
23.1 视图之间的关系 277
23.2 情境和功能视图的一致性 278
23.3 情境和信息视图的一致性 278
23.4 情境和部署视图的一致性 279
23.5 功能和信息视图的一致性 279
23.6 功能和并发视图的一致性 279
23.7 功能和开发视图的一致性 280
23.8 功能和部署视图的一致性 280
23.9 功能和运维视图的一致性 280
23.10 信息和并发视图的一致性 281
23.11 信息和开发视图的一致性 281
23.12 信息和部署视图的一致性 281
23.13 信息和运维视图的一致性 281
23.14 并发和开发视图的一致性 282
23.15 并发和部署视图的一致性 282
23.16 部署和运维视图的一致性 282
第四部分 视角
第24章 视角类型简介 284
第25章 安全性视角 286
25.1 对视图的适用性 287
25.2 关注点 287
25.2.1 资源 287
25.2.2 当事人 287
25.2.3 策略 287
25.2.4 威胁 288
25.2.5 机密性 288
25.2.6 完整性 288
25.2.7 可用性 288
25.2.8 可说明性 289
25.2.9 检测和恢复 289
25.2.10 安全机制 289
25.3 活动：应用安全视角 290
25.3.1 确定敏感资源 290
25.3.2 定义安全性策略 291
25.3.3 识别对系统的威胁 293
25.3.4 设计安全性实现 294
25.3.5 评估安全风险 296
25.4 架构策略 296
25.4.1 应用识别出的安全性原则 296
25.4.2 对用户进行身份验证 298
25.4.3 授权访问 298
25.4.4 确保信息保密性 299
25.4.5 确保信息的完整性 299
25.4.6 确保可负责性 300
25.4.7 保护可用性 300
25.4.8 整合安全性技术 301
25.4.9 提供安全性管理 301
25.4.10 使用第三方的安全性基础架构 301
25.5 问题和缺陷 302
25.5.1 复杂的安全性策略 302
25.5.2 未经验证的安全性技术 302
25.5.3 没有针对故障设计系统 302
25.5.4 缺少管理工具 303
25.5.5 技术驱动的方法 303
25.5.6 没有考虑时间源 303
25.5.7 过度依赖于技术 304
25.5.8 没有清晰的需求或模型 304
25.5.9 把安全性作为事后的想法 305
25.5.10 忽略内部人员的威胁 305
25.5.11 假设客户端是安全的 305
25.5.12 嵌入在应用程序代码中的安全性 306
25.5.13 零碎的安全性 306
25.5.14 临时的安全技术 306
25.6 检查列表 307
25.6.1 获取需求的检查列表 307
25.6.2 架构定义的检查列表 307
25.7 延伸阅读 308
第26章 性能和可伸缩性视角 309
26.1 对视图的适用性 310
26.2 关注点 310
26.2.1 响应时间 310
26.2.2 吞吐量 311
26.2.3 可伸缩性 312
26.2.4 可预测性 312
26.2.5 硬件资源需求 312
26.2.6 峰值负载行为 312
26.3 活动：应用性能和可伸缩性视角 313
26.3.1 获取性能需求 314
26.3.2 创建性能模型 314
26.3.3 分析性能模型 316
26.3.4 执行实际的测试 317
26.3.5 根据需求评估 317
26.3.6 重做架构 318
26.4 架构策略 318
26.4.1 优化重复的处理 318
26.4.2 通过复制减少竞争 319
26.4.3 对处理按优先级排序 320
26.4.4 合并相关的工作 321
26.4.5 随时间分发处理 321
26.4.6 最小化对共享资源的使用 321
26.4.7 重用资源和结果 322
26.4.8 分解和并行化 322
26.4.9 增强或扩展 323
26.4.10 舒缓降级 324
26.4.11 使用异步处理 324
26.4.12 放松事务的一致性 324
26.4.13 做出设计折中 325
26.5 问题和缺陷 325
26.5.1 不精确的性能和可伸缩性目标 325
26.5.2 不实际的模型 326
26.5.3 对复杂情况使用简单的度量 326
26.5.4 不合适的分区 326
26.5.5 无效的环境和平台假设 327
26.5.6 太多间接层 327
26.5.7 与并发相关的竞争 327
26.5.8 数据库竞争 328
26.5.9 事务过载 328
26.5.10 粗心地分配资源 329
26.5.11 忽视网络和进程中调用的区别 329
26.6 检查列表 330
26.6.1 针对获取需求的检查列表 330
26.6.2 针对架构定义的检查列表 330
26.7 延伸阅读 330
第27章 可用性和弹性视角 332
27.1 对视图的适用性 332
27.2 关注点 332
27.2.1 服务的类型 333
27.2.2 有计划的停机时间 333
27.2.3 未经计划的停机时间 334
27.2.4 维修时间 334
27.2.5 灾难恢复 334
27.3 活动：应用可用性和弹性视角 335
27.3.1 捕获可用性需求 335
27.3.2 创建可用性日程表 336
27.3.3 评估平台的可用性 337
27.3.4 评估功能可用性 339
27.3.5 根据需求进行评估 340
27.3.6 应用策略以重做架构 341
27.4 架构策略 342
27.4.1 选择容错硬件 342
27.4.2 使用高可用性集群和负载均衡 342
27.4.3 日志事务 343
27.4.4 应用软件可用性解决方案 344
27.4.5 选择或创建容错软件 344
27.4.6 设计故障 345
27.4.7 考虑组件复制 345
27.4.8 放松事务一致性 345
27.4.9 确定备份和灾难恢复解决方案 346
27.5 问题和缺陷 346
27.5.1 故障单点 346
27.5.2 级联故障 347
27.5.3 由于过载造成的不可用 348
27.5.4 过分激进的可用性需求 348
27.5.5 无效的错误侦测 349
27.5.6 对组件弹性的过度估计 349
27.5.7 忽略全球可用性需求 350
27.5.8 不兼容的技术 350
27.6 检查列表 351
27.6.1 针对需求获取的检查列表 351
27.6.2 针对架构定义的检查列表 351
27.7 延伸阅读 352
第28章 演进视角 353
28.1 对视图的适用性 354
28.2 关注点 354
28.2.1 产品管理 354
28.2.2 变化的量级 354
28.2.3 变化的维度 355
28.2.4 变化的可能性 355
28.2.5 变化的时间跨度 355
28.2.6 何时为变化支付 355
28.2.7 由外部因素驱动的变更 356
28.2.8 开发复杂度 356
28.2.9 知识的保存 356
28.2.10 变更的可靠性 357
28.3 活动：应用演进视角 357
28.3.1 描绘演进需求的特征 357
28.3.2 评估当前演进的难易程度 358
28.3.3 考虑演进的取舍 359
28.3.4 重做架构 359
28.4 架构策略 359
28.4.1 包含变更 359
28.4.2 创建可扩展的接口 360
28.4.3 应用促进变更的设计技术 361
28.4.4 应用基于元模型的架构样式 361
28.4.5 把变化点构建到软件中 362
28.4.6 使用标准的扩展点 362
28.4.7 达到可靠地变更 363
28.4.8 保存开发环境 364
28.5 问题和缺陷 364
28.5.1 对错误的维度按优先级排序 364
28.5.2 永远不会发生的变更 364
28.5.3 演进对重要质量属性的影响 365
28.5.4 过度依赖特定的硬件或软件 365
28.5.5 丢失开发环境 366
28.5.6 临时的发布管理 366
28.6 检查列表 367
28.6.1 对于需求获取的检查列表 367
28.6.2 对于架构设计的检查列表 367
28.7 延伸阅读 367
第29章 其他视角 369
29.1 可访问性视角 370
29.1.1 对视图的适用性 370
29.1.2 关注点 371
29.1.3 活动：应用可访问性视角 371
29.1.4 架构策略 371
29.1.5 问题和缺陷 372
29.1.6 检查列表 372
29.1.7 延伸阅读 373
29.2 开发资源视角 373
29.2.1 对视图的适用性 374
29.2.2 关注点 374
29.2.3 活动：应用开发资源视角 375
29.2.4 架构策略 375
29.2.5 问题和缺陷 376
29.2.6 检查列表 376
29.2.7 延伸阅读 377
29.3 国际化视角 377
29.3.1 对视图的适用性 377
29.3.2 关注点 378
29.3.3 活动：应用国际化视角 379
29.3.4 架构策略 379
29.3.5 问题和缺陷 379
29.3.6 检查列表 380
29.3.7 延伸阅读 380
29.4 位置视角 380
29.4.1 对视图的适用性 381
29.4.2 关注点 381
29.4.3 活动：应用位置视角 382
29.4.4 架构策略 382
29.4.5 问题和缺陷 383
29.4.6 检查列表 383
29.4.7 延伸阅读 384
29.5 法规视角 384
29.5.1 对视图的适用性 384
29.5.2 关注点 385
29.5.3 活动：应用法规视角 386
29.5.4 架构策略 386
29.5.5 问题和缺陷 386
29.5.6 检查列表 386
29.5.7 延伸阅读 387
29.6 易用性视角 387
29.6.1 对视图的适用性 387
29.6.2 关注点 388
29.6.3 活动：应用易用性视角 389
29.6.4 架构策略 389
29.6.5 问题和缺陷 389
29.6.6 检查列表 390
29.6.7 延伸阅读 390
第五部分 把所有内容组合起来
第30章 作为软件架构师工作 392
30.1 项目生命周期中的架构 392
30.1.1 小型和低风险项目中的架构 392
30.1.2 敏捷项目中的架构 393
30.1.3 计划驱动项目中的架构 395
30.1.4 大型项目中的架构 396
30.2 支持不同类型的项目 398
30.2.1 内部系统开发 398
30.2.2 新产品开发 399
30.2.3 企业服务 399
30.2.4 对已经存在系统的扩展 400
30.2.5 程序包实现 400
30.2.6 Internet支持程序 401
30.2.7 退役 401
附录A 其他视点集 402
参考文献 408
· · · · · · (收起)