软件构架实践

出版者:清华大学出版社

作者:林·马斯

页数:428

译者:车立红

出版时间:2012-6

价格:49.00元

装帧:简裝本

isbn号码:9787302080428

丛书系列:卡内基·梅隆大学软件工程丛书

具体描述

软件构架实践（第2版），ISBN：9787302080428，作者：（美）林·巴斯（Len Bass），（美）保罗·克莱门茨（Paul Clements），（美）瑞克·凯兹曼（Rick Kazman）著；车立红译；车立红译

作者简介

林·马斯 Len Bass：软件工程研究所（SEI）的一名高级软件工程师。他已经编著了5本书籍，并发表了大量关于软件工程、人机交互的论文。他曾经领导一个小组为飞行控制模拟器开发软件构架。目前，该构架已经被用美国空军标准。 保罗·克莱门茨 Paul Clements：软件工程

目录信息

第Ⅰ部分 预想构架
第1章 构架商业周期
1.1 构架的产生
1.2 软件过程和构架商业周期
1.3 什么样的构架才算好
1.4 小结
1.5 讨论题
第2章 什么是软件构架
2.1 软件构架概念澄清
2.2 其他观点
2.3 构架模式、参考模型和参考构架
2.4 为什么说软件构架非常重要
2.5 构架结构和视图
2.6 小结
2.7 可进一步参阅的文献
2.8 讨论题
第3章 A-7E案例分析：各种构架结构的运用
3.1 与构架商业周期的关系
3.2 需求与质量
3.3 A-7E航空电子系统的构架
3.4 小结
3.5 可进一步参阅的文献
3.6 讨论题
第Ⅱ部分 创建构架
第4章 理解质量属性
4.1 功能性和构架
4.2 构架和质量属性
4.3 系统的质量属性
4.4 实践中的质量属性场景
4.5 其他系统质量属性
4.6 商业质量属性
4.7 构架的质量属性
4.8 小结
4.9 可进一步参阅的文献
4.10 讨论题
第5章 实现质量属性
5.1 战术介绍
5.2 可用性战术
5.3 可修改性战术
5.4 性能战术
5.5 安全性战术
5.6 可测试性战术
5.7 易用性战术
5.8 战术与构架模式的关系
5.9 构架模式和样式
5.10 小结
5.11 可进一步参阅的文献
5.12 讨论题
第6章 空中交通管制：高可用性设计案例分析
6.1 与构架商业周期的关系
6.2 需求与质量
6.3 构架解决方案
6.4 小结
6.5 可进一步参阅的文献
6.6 讨论题
第7章 设计构架
7.1 生命期中的构架
7.2 设计构架
7.3 形成团队结构
7.4 创建骨架系统
7.5 小结
7.6 可进一步参阅的文献
7.7 讨论题
第8章 飞行模拟：构架可集成性案例分析
8.1 与构架商业周期的关系
8.2 需求与质量
8.3 构架解决方案
8.4 小结
8.5 可进一步参阅的文献
8.6 讨论题
第9章 构架编档
9.1 构架编档的使用
9.2 视图
9.3 选择相关视图
9.4 视图编档
9.5 跨视图的文档
9.6 统一建模语言
9.7 小结
9.8 可进一步参阅的文献
9.9 讨论题
第10章 软件构架重构
10.1 介绍
10.2 信息提取
10.3 数据库构造
10.4 视图融合
10.5 重构
10.6 示例
10.7 小结
10.8 可进一步参阅的文献
10.9 讨论题
第Ⅲ部分 分析构架
第11章 ATAM：一种进行构架评估的综合方法
11.1 ATAM的参与人员
11.2 ATAM的结果
11.3 ATAM的阶段
11.4 Nightingale系统：应用ATAM的案例分析
11.5 小结
11.6 可进一步参阅的文献
11.7 讨论题
第12章 CBAM：构架设计决策制定的定量方法
12.1 制定决策的上下文
12.2 CBAM的基础
12.3 实现CBAM
12.4 案例分析：NASA ECS项目
12.5 CBAM评估的结果
12.6 小结
12.7 可进一步参阅的文献
12.8 讨论题
第13章 万维网：可互操作性案例分析
13.1 与构架商业周期的关系
13.2 需求和质量
13.3 构架解决方案
13.4 基于Web的电子商务构架的演变
13.5 实现质量属性
13.6 当今的构架商业周期
13.7 小结
13.8 可进一步参阅的文献
13.9 讨论题
第Ⅳ部分 从一个系统到多个系统
第14章 软件产品线：重用构架资产
14.1 概述
14.2 软件产品线有效的原因
14.3 确定范围
14.4 产品线构架
14.5 采用软件产品线的困难之处
14.6 小结
14.7 可进一步参阅的文献
14.8 讨论题
第15章 CelsiusTech公司：产品线开发案例分析
15.1 与构架商业周期的关系
15.2 需求与质量
15.3 构架解决方案
15.4 小结
15.5 可进一步参阅的文献
15.6 讨论题
第16章 J2EE/EJB：工业标准计算基础结构的案例分析
16.1 与构架商业周期的关系
16.2 需求和质量
16.3 构架解决方案
16.4 系统部署决策
16.5 小结
16.6 可进一步参阅的文献
16.7 讨论题
第17章 Luther构架：使用J2EE的移动应用案例分析
17.1 与构架商业周期的关系
17.2 需求和质量
17.3 构架解决方案
17.4 Luther如何实现其质量目标
17.5 小结
17.6 可进一步参阅的文献
17.7 讨论题
第18章 用商业组件构建系统
18.1 组件对构架的影响
18.2 构架不匹配
18.3 作为搜索的基于组件的设计
18.4 ASEILM示例
18.5 小结
18.6 可进一步参阅的文献
第19章 未来的软件构架
19.1 重新认识构架商业周期
19.2 创建构架
19.3 生命期中的构架
19.4 商业组件的影响
19.5 小结
附录A 缩略语表
参考文献
· · · · · · (收起)

读后感

有点啃不动的感觉额，第三章的案例好多术语不理解。再坚持几天看看能否有所突破 mark一下 读到第三章51页了 不过看了看亚马逊的相关内容以及老师的推荐，这本书写的( ^_^ )不错嘛 可能是自己还需要净心读一读了

购得的这本书是第二版了，书中内容主要成文于2004年的第一版时期，改动不多，第二版比第一版增加了web方面的软件实践内容。 从亚马逊中搜索软件架构方面的书籍，这本书应该是较为权威的教材书了。相比国内的书籍来说，理论方面的内容较扎实。因为是一本实践类书籍，书...  

有点啃不动的感觉额，第三章的案例好多术语不理解。再坚持几天看看能否有所突破 mark一下 读到第三章51页了 不过看了看亚马逊的相关内容以及老师的推荐，这本书写的( ^_^ )不错嘛 可能是自己还需要净心读一读了

购得的这本书是第二版了，书中内容主要成文于2004年的第一版时期，改动不多，第二版比第一版增加了web方面的软件实践内容。 从亚马逊中搜索软件架构方面的书籍，这本书应该是较为权威的教材书了。相比国内的书籍来说，理论方面的内容较扎实。因为是一本实践类书籍，书...  

购得的这本书是第二版了，书中内容主要成文于2004年的第一版时期，改动不多，第二版比第一版增加了web方面的软件实践内容。 从亚马逊中搜索软件架构方面的书籍，这本书应该是较为权威的教材书了。相比国内的书籍来说，理论方面的内容较扎实。因为是一本实践类书籍，书...  

用户评价

这本关于软件架构实践的书籍，从我这个多年在行业里摸爬滚打的工程师的角度来看，着实是令人眼前一亮。首先，它并没有陷入那些高屋建瓴、脱离实际的理论漩涡。作者似乎深谙一线开发的痛点，对微服务、事件驱动、以及面向服务的架构（SOA）的演进脉络梳理得极为清晰。读起来的感觉，就像是跟着一位经验丰富的架构师进行了一次深入的“工地考察”。书中对各种架构模式的优缺点分析，不是那种教科书式的罗列，而是结合了具体业务场景的权衡取舍。比如，它详细阐述了在金融交易系统和内容分发网络中，为何倾向于选择不同的数据一致性策略，这种基于上下文的决策过程，对我后续指导团队设计系统非常有指导意义。尤其是关于“架构债务”的章节，简直是醍醐灌顶，它不再仅仅强调重构的必要性，而是提出了更具操作性的管理和偿还技术债的路线图，这比单纯地喊口号有效得多。书中提供的那些设计原则，比如“康威定律”的实际应用，以及如何利用领域驱动设计（DDD）来指导微服务边界的划分，都是我过去常常感到模糊地带，现在豁然开朗。总而言之，它是一本真正关注“如何落地”而非“是什么”的实践指南。

我必须承认，我对技术书籍的耐心有限，很多书读到一半就会因为内容重复或结构松散而束之高阁。但《软件架构实践》在结构组织上做到了极高的效率和完整性。它没有分散读者的注意力，而是紧紧围绕着“如何构建一个稳定、可维护、可演进的软件系统”这一核心目标展开。其中关于“模块化与耦合度”的章节，对如何利用设计模式和设计原则来控制系统复杂性，提供了非常细致的指导。作者似乎非常推崇“清晰性”高于“技巧性”，避免了过度使用晦涩难懂的最新技术术语，而是专注于那些跨越时间考验的核心原则。对我个人而言，最有价值的是书中关于“数据架构”与“应用架构”如何协同的论述。在很多项目中，这两个领域往往是脱节的，导致数据模型僵化而应用层疲于奔命。这本书提供了一个统一的视角，指导我们如何通过合理的数据分层和数据流设计，来支撑上层应用架构的灵活变化。这本书与其说是一本技术手册，不如说是一部关于构建持久化、高质量软件的“工匠心法”。

我原本以为，市面上关于软件架构的书籍大多是陈词滥调，无非是把经典论文翻来覆去地解读一遍，但翻开这本《软件架构实践》，我立刻意识到我错了。这本书最吸引我的地方，在于它对“非功能性需求”（如可扩展性、可靠性、安全性）的解构和量化。作者并没有把这些概念停留在抽象层面，而是提供了一整套评估和量化这些属性的方法论。比如，书中介绍了一种基于场景的风险分析矩阵，帮助架构师在设计初期就识别出系统的脆弱点，并提前设置好监控和应急预案。我特别欣赏它对“架构演进”的讨论，它没有假定任何系统都是一次性设计完成的完美品，而是将架构视为一个活的有机体，需要持续的投入和调整。书中举例说明了如何通过“反腐层”（Anti-Corruption Layer）来隔离老旧系统与新微服务之间的依赖，这个技术点在处理遗留系统迁移时显得尤为关键和实用。读完这部分内容，我感觉自己对“架构评审”这件事的理解提升了一个层次，不再是简单地检查技术栈是否新潮，而是深入到系统对业务变化的适应能力上。这本书记载的经验，更像是从无数次“踩坑”中总结出来的智慧结晶，非常接地气。

坦率地说，我是一个对“过于工程化”的书籍有点敬而远之的人，总觉得它们过于枯燥乏味，充满了流程图和术语堆砌。然而，这本书的叙事方式却意外地引人入胜。它采用了大量的案例研究，仿佛在讲述一个个真实的“项目故事”，让原本严肃的架构决策变得鲜活起来。比如，书中通过一个电商平台的订单处理流程重构案例，细致地展示了如何从单体到分布式迁移的每一步权衡，包括数据一致性、分布式事务的挑战，以及最终如何权衡 CAP 理论的取舍。这种叙述方式极大地降低了理解门槛，即便是初级工程师也能从中窥见高级架构师的思维过程。更难得的是，它对“架构师的角色”也有深刻的剖析，强调架构师不仅是技术决策者，更是沟通者和布道者，如何在跨职能团队中推动架构愿景的实现，书中给出了许多实用的沟通技巧和文档化建议。我感觉这不光是一本技术书，更是一本关于“技术领导力”的指南。那种将复杂问题拆解、用简洁的图示和清晰的逻辑链条进行阐述的功力，非一般人所能及。

对于一个专注于云原生和DevOps实践的开发者来说，我关注的核心是如何将架构设计无缝地融入持续交付的流水线中。这本书在这方面的着墨虽然不是主旋律，但其对“基础设施即代码”（IaC）与架构决策的耦合性分析，给我带来了很大的启发。它清晰地指出，现代架构的实现依赖于自动化，如果架构设计不能被清晰地表达为可执行的蓝图（如Terraform或CloudFormation脚本），那么理论上的优秀设计就很容易在部署环节“走样”。书中对“可观测性”（Observability）的探讨也十分到位，它将日志、指标、追踪（Tracing）视为架构的延伸反馈回路，强调架构师必须将这些非功能性需求嵌入到设计之初，而不是事后打补丁。特别是关于服务网格（Service Mesh）在治理复杂微服务网络中的作用，作者的分析角度非常独特，它不仅仅停留在技术选型，更深入到运维成本和学习曲线的考量上。读完这部分，我立刻着手调整了我们团队的CI/CD流程，确保架构蓝图的变更能够被自动验证其对系统约束的遵守情况。这本书的视野，完全跟上了技术栈的最新发展前沿。

粉红色封面这本是"软件体系结构"课程的两本指定参考书之一．

这种课有意思吗～

系统地介绍了实现构架的方法，质量属性，实现属性的战术和很多架构实例。

绕来绕去绕回这本，还是得读些演绎版本

还可以吧