恰如其分的软件架构
内容简介
本书描述了一种恰如其分的软件架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本，并从多个视角阐述了软件架构的建模过程和方法，包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍方法，而且还对方法和概念进行了归类和阐述，将软件架构设计融入开发实践中，与 敏捷开发方法有机地结合在一起，适合普通程序员阅读。
.
这是一本超值的书，案例丰富有趣，言简意赅，阅读轻松。当年如果读到这样的书，我可以少犯许多错误！渴望成为更为优秀软件设计师的读者，这本书绝对值得在你的书架上占有一席之地。
——Timothy J. Halloran博士，SureLogic Inc.工程总监
.
本书提出的独特视角让软件架构设计变得不再难以捉摸。恰如其分的软件架构概念及风险驱动的设计理念让人耳目一新。作者将架构设计原则与现实问题有机地结合起来，值得所有从事软件开发工作的人士阅读。
——Marcus Fontoura博士，Yahoo! Research首席科学家兼架构师
.
Fairbanks把笔墨聚集在“恰如其分”的软件架构上，这对于每一位想要使架构过程变得更容易的开发人员来说，都是极具吸引力的。本书通过详细的案例和建议，展示了如何用风险驱动来管理架构的建设和范围，重点突出，易于理解。同时，作者提供了软件架构学术方面的很多细节，这对那些对理论和实践都很感兴趣的开发人员非常有益。
——Bradley Schmerl博士，卡耐基梅隆大学计算机科学院资深系统科学家
.
George Fairbanks的《恰如其分的软件架构》一书中的风险驱动建模方法已经被NASA Johnson Space Center（JSC）成功地应用于eXtensible Information Modeler (XIM) 项目。项目的所有成员，从项目管理人员到开发人员，都必须遵循。实际上，这本书应该是每一位开发人员的必备工具。仅仅是讲述(代码模型和反模式)的部分，就值回书价了。
——Christopher Dean，
美国国家航空航天局约翰逊空间中心工程科学团队XIM首席架构师
.
《恰如其分的软件架构》教你如何在战略和战术上使用工具，以及如何为你的软件项目选择架构策略。无论你是一位开发人员还是架构师，本书都是你在架构过程中的必备参考资料。
——Nicholas Sherman，微软项目经理
.
作者将过程、生命周期、架构、建模及服务质量方面的最新理念集成在一个条理清楚的框架中。这个框架可以立即应用于你的 IT应用。Fairbanks的写作异常清晰、精确，同时具有很高的可读性和趣味性。《恰如其分的软件架构》是IT应用架构方面一个具有重要贡献的文献，对于企业应用架构师来说，也许会成为他们的标准参考资料。
——Ian Maung博士，花旗企业架构部门资深副总裁，Covance前企业架构总监
.
本书完全满足了那些软件开发实践者的关键需求，即如何有效地创建更加实际的系统。George常常运用自己的经验，并与学术理论相结合，为我们提供一个又一个概念模型、领域（或更广范围）内的最佳实践，以及在软件架构方面（如何更有用更现实）非常实用的指导。他在书中提出了基于风险的架构方法，并帮助我们认识到怎样才是“恰如其分”的。本书的问世为软件架构领域又增添了一份重要的文献。
——Desmond D’Souza, 《MAp and Catalysis》一书的作者，Kinetium, Inc.
.
很多系统和软件开发人员常常追问为什么要做，以及针对什么做软件架构，他们一定会感谢本书的作者在这本书中呈现了清晰的论证和精彩的推理；对于纠结何时，以及如何做架构的开发人员，也会在本书中找到恰如其分的指导，当然还有很多概念和思想。总之，本书简洁易懂，还有很多可供参考的内容——的确是一本架构精到、设计精心的好书！
——Shang-Wen Cheng博士，航空软件工程师
.
如果你打算阅读一本关于软件架构的书，那就选择这一本吧。《恰如其分的软件架构》覆盖了每一位程序员、开发人员、测试人员、架构师、经理都必须知道的软件架构的基本概念，它提供了很多在实战中非常实用的建议，而这只需要你花几个小时去阅读！
——Michael Keeling，专业软件工程师
.
本书展现了软件架构将如何帮助你来构建软件，而不会阻碍软件的构建；本书能够让你关注那些真正值得关注的关键性架构工作，从而避免影响编码工作。
——Kevin Bierhoff博士，专业软件工程师
......(更多)
作者简介
George Fairbanks在卡内基•梅隆大学获得软件工程专业博士学位，现任Rhino Research公司董事长。Rhino Research是一家专门提供软件开发培训及咨询的公司，总部设在美国科罗拉多州博尔德市。Georg还是软件体系结构工作会议WISCA（Working International Conference on Software Architecture）、国际软件维护大 会ICSM（International Conference on Software Maintenance）以及欧洲软件架构会议的委员会成员。他还是IEEE软件工程汇刊和IEEE软件的仲裁委员。
.
张逸是ThoughtWorks高级咨询师，程 序员。InfoQ中文站编辑。著译作包括《软件设计精要与模式》《WCF服务编程》《Java设计模式》以及评注版《重构：改善既有代码的设计》。目前居住于成都。
.
倪健是eBaoTech应用架构师，程序员。著作包括《简单之美：软件开发实践者的思考》《IT项目管理那些事儿》（与人合著）。目前居住于上海。
......(更多)
目录
第1章 概述 1
1.1 分治、知识与抽象 2
1.2 软件架构的三个案例 3
1.3 反思 5
1.4 视角转换 6
1.5 架构师构建架构 7
1.6 风险驱动的软件架构 8
1.7 敏捷开发者的架构 9
1.8 关于本书 10
第2章 软件架构 15
2.1 何为软件架构？ 16
2.2 软件架构为何重要 18
2.3 架构何时重要？ 22
2.4 推定架构 23
2.5 如何运用软件架构？ 24
2.6 架构无关的设计 25
2.7 专注架构的设计 26
2.8 提升架构的设计 27
2.9 大型组织中的架构 30
2.10 结论 31
2.11 延伸阅读 32
第3章 风险驱动模型 35
3.1 风险驱动模型是什么？ 37
3.2 你现在采用风险驱动了吗？ 38
3.3 风险 39
3.4 技术 42
3.5 选择技术的指导原则 44
3.6 何时停止 47
3.7 计划式设计与演进式设计 48
3.8 软件开发过程 51
3.9 理解过程变化 53
3.10 风险驱动模型与软件开发过程 55
3.11 应用于敏捷过程 56
3.12 风险与架构重构 58
3.13 风险驱动模型的替代方案 58
3.14 结论 60
3.15 延伸阅读 61
第4章 实例：家庭媒体播放器 65
4.1 团队沟通 67
4.2 COTS组件的集成 75
4.3 元数据一致性 81
4.4 结论 86
第5章 建模建议 89
5.1 专注于风险 89
5.2 理解你的架构 90
5.3 传播架构技能 91
5.4 作出合理的架构决策 92
5.5 避免预先大量设计 93
5.6 避免自顶向下设计 95
5.7 余下的挑战 95
5.8 特性和风险：一个故事 97
第6章 工程师使用模型 103
6.1 规模与复杂度需要抽象 104
6.2 抽象提供洞察力和解决手段 105
6.3 分析系统质量 105
6.4 模型忽略细节 106
6.5 模型能够增强推理 107
6.6 提问在前，建模在后 108
6.7 小结 108
6.8 延伸阅读 109
第7章 软件架构的概念模型 111
7.1 规范化模型结构 114
7.2 领域模型、设计模型和代码模型 115
7.3 指定与细化关系 116
7.4 主模型的视图 118
7.5 组织模型的其他方式 121
7.6 业务建模 121
7.7 UML的用法 122
7.8 小结 123
7.9 延伸阅读 123
第8章 领域模型 127
8.1 领域与架构的关系 128
8.2 信息模型 131
8.3 导航和不变量 133
8.4 快照 134
8.5 功能场景 135
8.6 小结 136
8.7 延伸阅读 137
第9章 设计模型 139
9.1 设计模型 140
9.2 边界模型 141
9.3 内部模型 141
9.4 质量属性 142
9.5 Yinzer系统的设计之旅 143
9.6 视图类型 157
9.7 动态架构模型 161
9.8 架构描述语言 162
9.9 小结 163
9.10 深入阅读 164
第10章 代码模型 167
10.1 模型-代码差异 167
10.2 一致性管理 171
10.3 架构明显的编码风格 174
10.4 在代码中表达设计意图 175
10.5 模型嵌入代码原理 177
10.6 表达什么 178
10.7 在代码中表达设计意图的模式 180
10.8 电子邮件处理系统预演 187
10.9 小结 193
第11章 封装和分割 195
11.1 多层级故事 195
11.2 层级和分割 197
11.3 分解策略 199
11.4 有效封装 203
11.5 创建封装接口 206
11.6 小结 210
11.7 深入阅读 210
第12章 模型元素 213
12.1 和部署相关的元素 214
12.2 组件 215
12.3 组件装配 219
12.4 连接器 223
12.5 设计决策 233
12.6 功能场景 234
12.7 (不变量(约束) 239
12.8 模块 239
12.9 端口 241
12.10 质量属性 246
12.11 质量属性场景 249
12.12 职责 251
12.13 权衡 252
12.14 小结 253
第13章 模型关系 255
13.1 投影(视图)关系 256
13.2 分割关系 261
13.3 组合关系 261
13.4 分类关系 261
13.5 泛化关系 262
13.6 指定关系 263
13.7 细化关系 264
13.8 绑定关系 268
13.9 依赖关系 269
13.10 使用关系 269
13.11 小结 270
13.12 深入阅读 271
第14章 架构风格 273
14.1 优势 274
14.2 柏拉图式风格对体验式风格 275
14.3 约束和以架构为中心的设计 276
14.4 模式对风格 277
14.5 风格目录 277
14.6 分层风格 277
14.7 大泥球风格 280
14.8 管道-过滤器风格 281
14.9 批量顺序处理风格 283
14.10 以模型为中心的风格 285
14.11 分发-订阅风格 286
14.12 客户端-服务器风格和多层 288
14.13 对等风格 290
14.14 map-reduce风格 291
14.15 镜像，支架和农场风格 293
14.16 小结 294
14.17 深入阅读 295
第15章 使用架构模型 297
15.1 理想的模型特性 297
15.2 和视图一起工作 303
15.3 改善视图质量 306
15.4 提高图的质量 310
15.5 测试和证明 312
15.6 分析架构模型 312
15.7 架构不匹配 318
15.8 选择你的抽象级别 319
15.9 规划用户界面 320
15.10 指定性模型对描述性模型 320
15.11 对现有系统进行建模 320
15.12 小结 322
15.13 深入阅读 323
第16章 结论 325
16.1 挑战 326
16.2 聚焦质量属性 330
16.3 解决问题，而不是仅仅对它们建模 331
16.4 使用导轨一样的约束 332
16.5 使用标准架构抽象 333
术语表 335
文献 347
索引 355
......(更多)
读书文摘
......(更多)
