内容简介

Michael Keeling是卡内基梅隆大学知名校友、IBM人工智能系统Watson的软件架构师，具有多年软件架构设计经验，他负责的项目从作战系统、搜索引擎到web应用，不一而足。

作品目录

第一部分 软件架构导论
第1章 成为软件架构师 3
1.1 软件架构师要做什么 4
1.2 什么是软件架构 7
1.3 成为团队的架构师 11
1.4 开发出色的软件 13
1.5 案例分析：Lionheart项目 14
1.6 预告 14
第2章 设计思维基础 15
2.1 设计思维的四条原则 15
2.2 运用思维模式 18
2.3 思考、动手、检查 21
2.4 预告 24
第二部分 架构设计原理
第3章 制定设计策略 27
3.1 找到够用的设计 27
3.2 决定前期做多少架构设计 29
3.3 用风险做向导 32
3.4 制订设计计划 36
3.5 Lionheart项目：目前的进展 37
3.6 预告 38
第4章 换位思考 39
4.1 找合适的人交谈 39
4.2 创建利益相关方关系图 40
4.3 了解业务目标 43
4.4 Lionheart项目：目前的进展 46
4.5 预告 47
第5章 挖掘关键架构需求 49
5.1 用约束限制设计选择 50
5.2 定义质量属性 51
5.3 对功能需求分类 56
5.4 找出其他影响架构的因素 57
5.5 挖掘关键架构需求 59
5.6 创建ASR工作簿 60
5.7 Lionheart项目：目前的进展 62
5.8 预告 62
第6章 主动选择架构 63
6.1 发散探索，聚合决策 63
6.2 接受约束 66
6.3 提升质量属性 67
6.4 为架构元素分配功能 72
6.5 设计，应变而生 74
6.6 Lionheart项目：目前的进展 75
6.7 预告 76
第7章 架构模式 77
7.1 什么是架构模式 77
7.2 分层模式 78
7.3 端口适配器模式 80
7.4 管道过滤器模式 81
7.5 面向服务架构模式 83
7.6 发布订阅模式 85
7.7 共享数据模式 86
7.8 多层模式 88
7.9 能力中心模式 89
7.10 开源贡献模式 91
7.11 大泥球模式 92
7.12 发现新架构模式 92
7.13 Lionheart项目：目前的进展 93
7.14 预告 93
第8章 建立模型，化繁为简 95
8.1 推演架构 96
8.2 设计元模型 97
8.3 让模型融入代码 104
8.4 Lionheart项目：目前的进展 108
8.5 预告 108
第9章 召开架构设计研讨会 109
9.1 筹划架构设计研讨会 110
9.2 挑选设计方法 115
9.3 挑选参与者 116
9.4 会议管理 118
9.5 与远程团队协作 121
9.6 Lionheart项目：目前的进展 122
9.7 预告 122
第10章 展示设计决策 123
10.1 用不同的视图展现架构 124
10.2 绘制出色的图表 132
10.3 Lionheart项目：目前的进展 138
10.4 预告 139
第11章 描述架构 139
11.1 讲述完整的故事 140
11.2 因地制宜，选择描述方法 141
11.3 尊重受众 145
11.4 围绕利益相关方关注点组织视图 148
11.5 阐述决策的逻辑依据 151
11.6 Lionheart项目：目前的进展 152
11.7 预告 153
第12章 架构评估 153
12.1 评估得真知 154
12.2 检验设计 154
12.3 举办评估研讨会 160
12.4 尽早评估，反复评估，持续评估 164
12.5 Lionheart 项目：目前的进展 168
12.6 预告 168
第13章 鼓励团队参与架构设计 169
13.1 提倡架构师思维 170
13.2 传授技能，辅助决策 171
13.3 为团队创造实践机会 172
13.4 设计下放 173
13.5 共同设计架构 177
13.6 Lionheart项目：大结局 178
13.7 预告 179
第三部分 架构师的工具箱
第14章 理解问题的常用方法 183
14.1 方法1：二选一 184
14.2 方法2：移情图 186
14.3 方法3：GQM研讨会 189
14.4 方法4：利益相关方访谈 191
14.5 方法5：假设清单 194
14.6 方法6：质量属性网络 195
14.7 方法7：微型质量属性研讨会 197
14.8 方法8：观点填空 202
14.9 方法9：响应度量稻草人 205
14.10 方法10：利益相关方关系图 207
第15章 探索解决方案的常用方法 209
15.1 方法11：架构拟人化 210
15.2 方法12：架构演变记录 212
15.3 方法13：组件-功能-协作者卡片 215
15.4 方法14：概念图 219
15.5 方法15：分而治之 221
15.6 方法16：事件风暴 225
15.7 方法17：团队海报 228
15.8 方法18：循环设计 230
15.9 方法19：白板涂鸦 233
第16章 展示设计的常用方法 235
16.1 方法20：架构决策记录 236
16.2 方法21：架构主旨 239
16.3 方法22：背景图 241
16.4 方法23：精选阅读列表 242
16.5 方法24：启动计划书 243
16.6 方法25：模块化分解图 246
16.7 方法26：未采纳的决策 248
16.8 方法27：制作原型，用于学习或决策 250
16.9 方法28：时序图 251
16.10 方法29：系统隐喻 254
第17章 评估设计方案的常用方法 257
17.1 方法30：架构简报 258
17.2 方法31：代码评审 260
17.3 方法32：决策矩阵 263
17.4 方法33：观察系统表现 265
17.5 方法34：问题-评论-关注事项 267
17.6 方法35：风险风暴 269
17.7 方法36：合理性检查 271
17.8 方法37：场景排查 273
17.9 方法38：画草图做比较 277
附录 贡献者简介 279
索引 281
致谢 296
· · · · · ·

作者简介

Michael Keeling是卡内基梅隆大学知名校友、IBM人工智能系统Watson的软件架构师，具有多年软件架构设计经验，他负责的项目从作战系统、搜索引擎到web应用，不一而足。

精彩摘录

你需要折中，也可能会犯错误。在开发系统的过程中，还会不断给架构引入技术债务。

——引自章节：1.1软件架构师要做什么4

架构师应该指明技术债务，帮助利益相关方决定采取何种措施管理它们

——引自章节：1.1软件架构师要做什么4