恰如其分的软件架构

出版者:华中科技大学出版社

作者:George Fairbanks

页数:376

译者:张逸

出版时间:2013-9-1

价格:88.00

装帧:平装

isbn号码:9787560990750

具体描述

本书描述了一种恰如其分的软件架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本，并从多个视角阐述了软件架构的建模过程和方法，包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍方法，而且还对方法和概念进行了归类和阐述，将软件架构设计融入开发实践中，与 敏捷开发方法有机地结合在一起，适合普通程序员阅读。

.

这是一本超值的书，案例丰富有趣，言简意赅，阅读轻松。当年如果读到这样的书，我可以少犯许多错误！渴望成为更为优秀软件设计师的读者，这本书绝对值得在你的书架上占有一席之地。

——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
· · · · · · (收起)

读后感

华中科技大学出版社的徐定翔问我意见，了解我对Just Enough Software Architecture这本书的观感，看是否值得引进。时间是在2010年。从一开始，我就被书名中的Just Enough理念所吸引。它让我想起宋玉的东家姑娘，“增之一分则太长，减之一分则太短”那种不可言说的美丽。我在心...  

原文: http://liguanglei.name/blogs/2014/05/31/just-enough-software-architecture/ 本书算是个总结整理, 没看出提出了什么新的观点和方法 本书倒是明确了几个词汇, 丰富了设计时可用与思考和交流的语言, 回答了为啥工程师和项目经理总是对优先级有不同理解的问题  

原文: http://liguanglei.name/blogs/2014/05/31/just-enough-software-architecture/ 本书算是个总结整理, 没看出提出了什么新的观点和方法 本书倒是明确了几个词汇, 丰富了设计时可用与思考和交流的语言, 回答了为啥工程师和项目经理总是对优先级有不同理解的问题  

华中科技大学出版社的徐定翔问我意见，了解我对Just Enough Software Architecture这本书的观感，看是否值得引进。时间是在2010年。从一开始，我就被书名中的Just Enough理念所吸引。它让我想起宋玉的东家姑娘，“增之一分则太长，减之一分则太短”那种不可言说的美丽。我在心...  

前几天，朋友送了一本书给我《恰如其分的软件架构》，一看副标题，“风险驱动的设计方法”，嗯？“风险”，这是我最想了解的，最近遭遇太多太多风险了，做梦都在想怎么化解各种风险。 想想现在的架构工作，我们总会发现这样一个情景：架构师总是在系统投产上线后，进行项目总...  

用户评价

读完这本书，我感到自己对“架构”这个概念的理解有了一个质的飞跃。过去总觉得架构就是画图、选技术栈，但这本书让我明白，架构的本质其实是**决策的艺术**，是关于如何在不完美信息下做出最优取舍的持续过程。作者对不同架构风格的批判性分析尤其精彩，他没有盲目推崇微服务或单体架构，而是详尽地阐述了每种选择背后的隐含成本和收益。这种不偏不倚、实事求是的态度，非常值得称赞。书中穿插的许多小故事和比喻，生动形象，让那些抽象的理论变得具体可感。我尤其喜欢其中关于“沟通成本”和“认知负荷”的论述，这往往是决定项目成败的关键因素，却常常被主流书籍忽略。这本书更像是一本关于“如何成为一个更成熟的软件工程师”的指南，而不仅仅是一本技术手册。

这本书真正做到了“少即是多”。它没有试图涵盖所有最新的框架或技术名词，反而专注于提炼出那些经久不衰的、跨越技术周期的设计原则。我特别欣赏作者对于“复杂性管理”的深刻见解。他将系统复杂性视为一种熵增过程，并详细阐述了如何通过清晰的边界、明确的责任划分以及恰当的抽象层次来有效对抗这种熵增。书中的论证逻辑严密，每一步推导都建立在对现实约束的深刻理解之上。读完之后，我感觉自己像被“净化”了一样，不再被那些浮夸的营销术语所迷惑，而是能够专注于构建真正能为业务带来价值的、可持续演进的系统。对于任何希望从高级工程师晋升为架构师的人来说，这本书提供的思维训练，比任何最新的技术认证都来得更有价值。

这本书的结构组织非常巧妙，它不像传统技术书籍那样按部就班地介绍概念，而是通过一系列相互关联的场景和挑战来展开论述。这种叙事方式极大地提升了阅读的沉浸感。我发现自己不是在“学习”知识，而是在“经历”那些架构师们必须面对的权衡博弈。作者在处理非功能性需求（如可扩展性、可靠性）时，总是将它们置于业务目标和资源限制的背景下去讨论，这才是真实世界的写照。书中对于**“僵化”和“弹性”**之间关系的探讨尤为深刻，它指出架构的价值不在于它当前有多么健壮，而在于它未来能以多低的成本适应变化。这本书的语言风格有一种老派的严谨和智慧，读起来需要慢下来细品，但每一次停顿都会带来新的领悟，绝对不是那种可以快速翻阅的速食读物。

坦白讲，初拿到这本书时，我对它的期望值并不高，以为又是市面上泛滥的那种“大而空”的架构综述。然而，阅读过程却带来了惊喜。作者对“恰如其分”这个核心理念的诠释，深入到了设计的每一个层面——从模块划分到接口设计，甚至到团队组织结构。最让我印象深刻的是关于“过度设计”的警示。它用犀利的笔触剖析了许多团队如何因为追求“完美”而陷入泥潭，强调了**最小可行架构（MVA）**的重要性。这种务实的、反对教条主义的立场，在当前追求快速迭代的行业环境中显得尤为珍贵。阅读时，我脑海中不断浮现出过往项目的影子，那些本可以避免的返工和困境，原来都是因为在某个关键节点上，没有把握好“分寸”。这本书提供了一个绝佳的对照镜，让我得以反思过去的决策失误。

这本书实在是太对我的胃口了，简直是为我量身定做的。我一直都在寻找一本能够深入浅出地讲解软件架构核心思想的书籍，而不是那种堆砌术语和流行框架的教科书。作者的叙述方式非常接地气，没有那种高高在上的说教感，反而像是一位经验丰富的老前辈在分享他的心路历程。他没有直接告诉我“应该怎么做”，而是通过一系列引人深思的案例和权衡分析，引导我去思考“为什么这么做才是最好的选择”。特别是关于系统演进和技术债务的部分，描述得入木三分。我常常在实际工作中遇到各种看似无解的困境，而这本书提供的思维框架，让我能够跳出具体的实现细节，从更高的维度去审视问题，从而找到了更优雅的解决方案。它不是提供一剂万能药，而是教会你如何根据具体情境，调配出最适合你团队和项目的“药方”。这种注重“度”和“平衡”的理念，贯穿始终，让人受益匪浅。

风险驱动的架构设计主旨是软件架构所付出的精力要与面对的风险成正比。先是讲解了风险驱动的主概念，然后将其细化成各个方面，并试图将设计意图逐级传递下去。

个人感受：以分析思考本身为基础 上升到架构。大篇篇幅讨论了架构的核心：『模型』；个人觉得亮眼的一章是『第13章 模型关系』，其实说的是很Meta的概念分析，第一次在这本书中看到。能从这个角度讨论架构主题，是非常难得的一本架构书籍；但是对于初学者来说这条路径是最难的，所以这本书提供了案例来配合讲解。

多看阅读# 3.3 分。em，复杂的心情，可能我项目经验或者项目神经太少，或者我还是不适合做架构师角色的人吧……

几个概念定义的挺好，但有用的知识还是少一些

这本书讲述软件工程中的架构设计，却带有一定的学术成分，关于架构的探讨，引用了大量学术型的观点，既有宏观的战略讨论，从功能到性能，引出以风险为中的论点值得关注。又有模型、架构与详细设计的关系与异同，业务模型、设计模型、代码模型的转承与关系，理论结合案例、经验，值得参考。