恰如其分的软件架构
出版社:华中科技大学出版社
出版日期:2013-9-1
ISBN:9787560990750
作者:George Fairbanks
页数:376页
内容概要
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
作者简介
本书描述了一种恰如其分的软件架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本，并从多个视角阐述了软件架构的建模过程和方法，包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍方法，而且还对方法和概念进行了归类和阐述，将软件架构设计融入开发实践中，与 敏捷开发方法有机地结合在一起，适合普通程序员阅读。
.
这是一本超值的书，案例丰富有趣，言简意赅，阅读轻松。当年如果读到这样的书，我可以少犯许多错误！渴望成为更为优秀软件设计师的读者，这本书绝对值得在你的书架上占有一席之地。
——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博士，专业软件工程师
发布书评
精彩书评 (总计3条)
-
华中科技大学出版社的徐定翔问我意见，了解我对Just Enough Software Architecture这本书的观感，看是否值得引进。时间是在2010年。从一开始，我就被书名中的Just Enough理念所吸引。它让我想起宋玉的东家姑娘，“增之一分则太长，减之一分则太短”那种不可言说的美丽。我在心里说，架构设计就需要这样。我当时并没有看到本书，只是到Amazon上找到了几篇英文原版样章。犹记得我在读到第一章介绍的RackSpace案例时那种兴奋之情。于是，我迫切地向徐定翔强烈推荐引进这本书，而我则毛遂自荐，希望能作为本书的译者。之后，我在InfoQ上看到对本书的《访谈和书摘》，进一步加强了我翻译本书的信念。于是，出版社开始与作者Fairbanks联系，然而从此音讯如石沉大海。时针指向2011年，我对于本书是否被引进，是否由我翻译，一切未知。我觉得我可能错过了它，思之仍觉怅然。谁知到了九月，消息突然确定，而徐大编辑就不容分说地直接把原书给我寄来了。拿到沉甸甸的书，第一面就为本书的装帧而惊喜。心里想，我这一辈子若能写出这样一本书，绝对值得生命走过的这一遭了。我并没有迫不及待地开始翻译，这就好似遇到珍馐美味，需得先赏其色，闻其香，然后再品其味。我每天抱着这本书饶有兴味地开始阅读之旅。阅读之旅确乎如行山阴道，沿途之美，目不暇接；可一想到翻译，这种美景就成了一种折磨，因为我害怕辜负这一美景。翻译之初我就举步维艰，那些词语放在那里，我却无法解开“封印”将它们取出来，即使取出来，却又找不到存放的合适位置。一些翻译隐隐约约浮现着，当我竭力去揭开这些词语的真面目时，无论如何用力，总也不能够着。翻译就好像那些年我们一起追过的女孩——追不到，痛苦；追到了，销魂。翻译进度像蜗牛一样的爬着，我终于决定求助了。辗转寻找了好多朋友，都以各种理由拒绝或者放弃了。翻译讲解软件架构的书，确乎不是一件轻松的事儿。那个时候，我的Buddy肖鹏正从翻译《面向模式的软件架构》第五卷的泥潭中爬了出来。每一提及他的这段翻译经历，脸上就会浮现出不堪回首的表情，如看了恐怖片。终于，事情得到转机，最开始是倪健的雪中送炭，再有高翌翔的锦上添花，随着我们这个三人组的建立，翻译才算开始走向正规，我才有了交稿的信心。自从开始翻译这本书后，我与人谈架构，动辄就会提及“Just Enough，恰如其分”。我像祥林嫂一般地推介着Fairbanks提出的风险驱动模型，并认真地实践着这一模型。我开始对演进的架构有了更深入的理解。我写了《设计恰如其分的架构》这篇博客来详细阐述我对演进式架构的理解。在2011年我参加的技术会议上，我也反复讲解了如何遵循简单之美的原则，运用风险驱动模型设计恰如其分的架构。2012年，在我参加的一个项目中需要针对遗留系统进行技术栈迁移。我撰写了文章《遗留系统的技术栈迁移》，提到了“风险驱动模型”，并在2013年的Scrum Gathering会议上分享了我的一些想法。当然，这个模型并不是锤子，更不是银弹。它更近似于质量属性驱动的架构设计，我们要满足的质量属性，可能就是我们在做架构时需要面对的风险；而在Roy Fielding的那篇关于REST的著名论文中，也提到了对约束的识别，并演示了如何从一个空约束，通过逐步添加约束演化为REST风格的架构。从某种程度上，架构的约束可能是一种风险，也可能成为设计的驱动力。前几天，我参加Agile China 2013，与我新认识的一位朋友范钢聊到了关于架构重构的问题。事实上，面向对象软件开发到现在，已有十余年之久；各种经验、模式与原则甚嚣尘上并得到较好的推广。然而新的方法、新的语言乃至新的思想仍然层出不穷，尤其是在互联网开发、大数据处理以及移动开发的冲击下，传统软件开发似乎已经开始走向末路。“只见新人笑，不见旧人哭”！？？是，也不是。实际上，在传统的企业开发领域，各种大型系统仍然像一艘庞大如巨型海兽一般的船舰在海面缓缓行驶，它或许就是沉没之前的泰坦尼克，一切还都安然无恙，你甚至可以听到船头甲板传来的悠扬的小提琴声；然而，冰川就在远处出没，船长还未察觉。我们该怎么办？这样的巨型船舰，自然不可能如艨艟快艇那般的敏捷，即使是360度的转身，也可以玩得如此漂亮、优雅。这些大型的企业级软件系统已经走过了漫长的历程，它们如此巨大以至于我们只能看到它的一角，它们的零部件如此复杂以至于没有人能够彻底弄懂。我们必须认识到，这些系统是最有权力的系统，它们很有可能掌握了人类生活的根本命脉——金融管理、股市交易、生命健康、医疗管理、机械制造、国防安全、航空、航天……它们就像政治界、金融界的那些巨头，要是患了病咳嗽两声，也许世界都要抖一抖。它们可以轻易改变吗？不能！然而若是不寻求改变，这些系统会宿命地走向衰亡。若我们无法承受重写的成本，唯一的办法或许就是架构的重构。我们必须清晰地认识到这一点。而我认为，风险驱动模型恰恰可以作为架构重构的指导原则。在进行重构之前，我们需要充分评估重构的价值，回答“为什么我们需要重构”的问题；然后去识别风险。在开始重构之前，我们需要尽可能做到万无一失。风险自然是不可避免的，但如果我们能事先识别出这些风险，就能有的放矢地选择正确的技术。风险驱动模型的第三步，则是评估风险是否得到有效缓解。不要轻视这一步！重构往往意味着还债。可是，我们该用什么来说服管理者们付出成本去做一些看似没有产生直接利益的任务呢？答案就是用数据来说话，通过比较重构前后的系统健康指标，可以加重说服老板的砝码。当然，毫无疑问，这个过程一定是迭代的。我想，通过这次交谈，我进一步找到了“风险驱动模型”适用的场景。而这正是我翻译并推荐本书的根本意义。本书可以在当当网购买。 -
前几天，朋友送了一本书给我《恰如其分的软件架构》，一看副标题，“风险驱动的设计方法”，嗯？“风险”，这是我最想了解的，最近遭遇太多太多风险了，做梦都在想怎么化解各种风险。想想现在的架构工作，我们总会发现这样一个情景：架构师总是在系统投产上线后，进行项目总结时才发觉现行的架构与最初相差甚远，甚至是大相径庭，但是细想一下，每一个改动都是有理有据的，都有存在的理由。然而，这个结果，投产后的架构，却不是我们希望看到的，它是一个妥协的产物，——期望的架构已经远离了我们。在商界有种说法，“CEO是公司里最后一个知道公司要破产的人”，在技术领域，是不是可以说“架构师是团队中最有一个知道架构即将被推翻的人”？哎，可能还真是。想一下我们的架构是从何而来的。很简单，是从头脑中投射出来的，简单的说，就是知识+经验的产物，经过多日的熬夜奋战，终于，一份叫做“架构设计说明书”的文档诞生了。在这个过程中，我们付出了艰辛的劳动，考虑了诸多的特殊和异常场景，建立了丰富的模型，制定了详细的数据流程，想当然的认为它能够适应领域内的大部分场景，但通常情况下，我们是错的。于是，我决定看看这本“风险驱动设计”，看看如何从风险的角度构架我们的系统，看后收益匪浅。这本书对架构建模进行了深层次的分析，提出抽象规模和复杂度、分析系统质量、忽略细节等等技法，感觉完全可以套用，以前做架构模型没思考这么深。这本书还提到了架构风格，这是我比较欣赏的，架构风格是“元素和约束组成的语言”，其可以预制约束集、统一理解、减少沟通损耗、设计重用、保证质量等等优势，还介绍了柏拉图式风格、分层风格、大泥球风格等，甚是受用。估计这本书在国内流行不起来，原因是大家都在忙着写代码，毕竟在世人眼里中Coder才是代表IT技术的。但是如果你的目标不仅仅是写代码，而是想统揽全局，向架构师方向发展的话，建议你读读这本书。还有，这本书翻译的非常专业，没有丝毫机器翻译的味道，而且作者对技术的理解也非常到位，整体看下来就是一气呵成，通顺流畅，值得推荐。秦小波 -
太泛，罗列了一大堆东西都没什么价值，几乎没有值得细读地方。个人观点：唯一可以品位一下的就是“Just Enough Software Architecture”书名的这几个字。作为一个优秀的架构师，必须具备出色的抽象和总结能力，在这个基础上，自然应该能够理清楚架构的重点和轻重缓急，在这个前提下进行的架构，一定程度上就是采用了风险驱动的方式，但又不是照本宣科、僵化的采用。
精彩短评 (总计28条)
-
总结下，要一点点改进 -
评估风险，然后在架构设计阶段使所评估的风险降到最低。一切以降低风险为目标，从理论上来看，是一个比较高效的开发模式。 -
案例丰富有趣，言简意赅，阅读轻松，值得软件设计师仔细阅读。 -
减少风险的定义很有意思。视图和各个架构的思想都能做到清晰和深入简出。译者的功力也不错，难得 -
赞同那个谁的观点：没看出提出了什么新的观点和方法 本书倒是明确了几个词汇, 丰富了设计时可用与思考和交流的语言, 回答了为啥工程师和项目经理总是对优先级有不同理解的问题 -
软件开发要先识别风险并排优先级，然后采用合适的软件架构，最后评估风险是否消除或降低。采用何种架构和设计方式完全取决于风险的大小，这也就是所谓的恰如其分的软件架构。书中还介绍了建模方法，包括设计模型，领域模型和代码模型，以及模型之间的关系。 -
看了前面几章，感觉没有预期的好，不想看了 -
提出了以风险为驱动的设计理念，回答了要做多少设计，何时停止设计的问题。第二部分详细描述了设计时使用的各种模型，算是比较系统性的梳理。 -
书写的有些杂乱，草草看完，头有点晕，谁扶我一下。#话说，目前没看到架构方面有什么好书# -
我自己翻译的书，自然要力荐。本书已经交付印刷，估计八月就可以买到了。 -
几个概念定义的挺好，但有用的知识还是少一些 -
关于软件架构的书也读过一些。这是我觉得最精彩的一本。它不仅告诉你如何进行架构设计，还告诉你为什么要这么做。 -
本书主题是风险驱动的架构设计，也介绍了一些架构，更多是方法，看的时候可能对知识实践的理解不深，也还缺乏量化分析的经验。不过确实如书中所说，一个软件系统不可能没有架构，只是前期花了很大成本，还是自然浮现。恰到好处就行 -
#多看阅读# 3.3 分。em，复杂的心情，可能我项目经验或者项目神经太少，或者我还是不适合做架构师角色的人吧…… -
翻译不太好，后面几章完全看不下去…… -
然并卵，阐述了规范化模型的3个模型：领域，设计，代码。围绕这三者的的风险矛盾 -
由于没有完整版，只读了抢先版，已经被内容深深吸引了。以前我认为软件架构以及设计，是每个软件所必须的，但作者的just enough让我如梦初醒，架构设计只是为了规避软件的风险，如果你能把握住所有的风险，没有好的架构也一样。 -
风险控制 -
不错的一本书，但是架构本身就是一件很模糊的概念，每个人都会有自己的认识和见解，所以对这本书来说，并没有得到原先预期的架构原则，但是还是一些其他的概念和知识。 -
大部分内容了解过。书是翻完的。 -
太泛了，干货不多，基本翻完了 -
简而言之, 就是寻找可以降低风险的架构. -
可以了解一些关于软件架构的概念，总的来说还是有点虚和偏学术性。很难直接应用。 -
太专了，果断不是我的菜啊！ -
太泛，罗列了一大堆东西都没什么价值，几乎没有值得细读地方。
个人观点：唯一可以品位一下的就是“Just Enough Software Architecture”书名的这几个字。作为一个优秀的架构师，必须具备出色的抽象和总结能力，在这个基础上，自然应该能够理清楚架构的重点和轻重缓急，在这个前提下进行的架构，一定程度上就是采用了风险驱动的方式，但又不是照本宣科、僵化的采用。 -
浙江图书馆 -
第十四章对各种架构风格的介绍真是提纲契领，看完真有醍醐灌顶的感觉。 -
明白自己在做什么？了解别人在做什么？清楚以后该怎么做？——答案尽在《恰如其分的软件架构》！！！