本书描述了一种恰如其分的架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本,并从多个视角阐述了软件架构的建模过程和方法,包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍方法,而且还对方法和概念进行了归类和阐述,将软件架构设计融入开发实践中,与敏捷开发方法有机地结合在一起,适合普通程序员阅读。
George Fairbanks在卡内基·梅隆大学获得软件工程专业博士学位,现任Rhino Research公司董事长。Rhino Research是一家专门提供软件开发培训及咨询的公司,总部设在美国科罗拉多州博尔德市。
张逸是ThoughtWorks高级咨询师,程 序员。InfoQ中文站编辑。著译作包括《软件设计精要与模式》《WCF服务编程》《Java设计模式》以及评注版《重构:改善既有代码的设计》。目前居住于成都。
倪健是eBaoTech应用架构师,程序员。著作包括《简单之美:软件开发实践者的思考》《IT项目管理那些事儿》(与人合著)。目前居住于上海。
第1章 概述
1.1 分治、知识与抽象
1.2 软件架构的三个案例
1.3 反思
1.4 视角转换
1.5 架构师构建架构
1.6 风险驱动的软件架构
1.7 敏捷开发者的架构
1.8 关于本书
第2章 软件架构
2.1 何为软件架构?
2.2 软件架构为何重要
2.3 架构何时重要?
2.4 推定架构
2.5 如何运用软件架构?
2.6 架构无关的设计
2.7 专注架构的设计
2.8 提升架构的设计
2.9 大型组织中的架构
2.10 结论
2.11 延伸阅读
第3章 风险驱动模型
3.1 风险驱动模型是什么?
3.2 你现在采用风险驱动了吗?
3.3 风险
3.4 技术
3.5 选择技术的指导原则
3.6 何时停止
3.7 计划式设计与演进式设计
3.8 软件开发过程
3.9 理解过程变化
3.10 风险驱动模型与软件开发过程
3.11 应用于敏捷过程
3.12 风险与架构重构
3.13 风险驱动模型的替代方案
3.14 结论
3.15 延伸阅读
第4章 实例:家庭媒体播放器
4.1 团队沟通
4.2 COTS组件的集成
4.3 元数据一致性
4.4 结论
第5章 建模建议
5.1 专注于风险
5.2 理解你的架构
5.3 传播架构技能
5.4 作出合理的架构决策
5.5 避免预先大量设计
5.6 避免自顶向下设计
5.7 余下的挑战
5.8 特性和风险:一个故事
第6章 工程师使用模型
6.1 规模与复杂度需要抽象
6.2 抽象提供洞察力和解决手段
6.3 分析系统质量
6.4 模型忽略细节
6.5 模型能够增强推理
6.6 提问在前,建模在后
6.7 小结
6.8 延伸阅读
第7章 软件架构的概念模型
7.1 规范化模型结构
7.2 领域模型、设计模型和代码模型
7.3 指定与细化关系
7.4 主模型的视图
7.5 组织模型的其他方式
7.6 业务建模
7.7 UML的用法
7.8 小结
7.9 延伸阅读
第8章 领域模型
8.1 领域与架构的关系
8.2 信息模型
8.3 导航和不变量
8.4 快照
8.5 功能场景
8.6 小结
8.7 延伸阅读
第9章 设计模型
9.1 设计模型
9.2 边界模型
9.3 内部模型
9.4 质量属性
9.5 Yinzer系统的设计之旅
9.6 视图类型
9.7 动态架构模型
9.8 架构描述语言
9.9 小结
9.10 深入阅读
第10章 代码模型
10.1 模型-代码差异
10.2 一致性管理
10.3 架构明显的编码风格
10.4 在代码中表达设计意图
10.5 模型嵌入代码原理
10.6 表达什么
10.7 在代码中表达设计意图的模式
10.8 电子邮件处理系统预演
10.9 小结
第11章 封装和分割
11.1 多层级故事
11.2 层级和分割
11.3 分解策略
11.4 有效封装
11.5 创建封装接口
11.6 小结
11.7 深入阅读
第12章 模型元素
12.1 和部署相关的元素
12.2 组件
12.3 组件装配
12.4 连接器
12.5 设计决策
12.6 功能场景
12.7 (不变量(约束)
12.8 模块
12.9 端口
12.10 质量属性
12.11 质量属性场景
12.12 职责
12.13 权衡
12.14 小结
第13章 模型关系
13.1 投影(视图)关系
13.2 分割关系
13.3 组合关系
13.4 分类关系
13.5 泛化关系
13.6 指定关系
13.7 细化关系
13.8 绑定关系
13.9 依赖关系
13.10 使用关系
13.11 小结
13.12 深入阅读
第14章 架构风格
14.1 优势
14.2 柏拉图式风格对体验式风格
14.3 约束和以架构为中心的设计
14.4 模式对风格
14.5 风格目录
14.6 分层风格
14.7 大泥球风格
14.8 管道-过滤器风格
14.9 批量顺序处理风格
14.10 以模型为中心的风格
14.11 分发-订阅风格
14.12 客户端-服务器风格和多层
14.13 对等风格
14.14 map-reduce风格
14.15 镜像,支架和农场风格
14.16 小结
14.17 深入阅读
第15章 使用架构模型
15.1 理想的模型特性
15.2 和视图一起工作
15.3 改善视图质量
15.4 提高图的质量
15.5 测试和证明
15.6 分析架构模型
15.7 架构不匹配
15.8 选择你的抽象级别
15.9 规划用户界面
15.10 指定性模型对描述性模型
15.11 对现有系统进行建模
15.12 小结
15.13 深入阅读
第16章 结论
16.1 挑战
16.2 聚焦质量属性
16.3 解决问题,而不是仅仅对它们建模
16.4 使用导轨一样的约束
16.5 使用标准架构抽象
术语表
文献
索引
第1章概述
随着岁月的推移,软件系统无论是规模还是复杂度都在呈数量级增长。作为软件的构建者,这种非凡的变化带给我们的惊叹远甚于恐慌。设想我们采用同样的方式让篮球比赛不停地扩大规模,在10年内,从最初的5名球员,增加到50名球员,再到500名球员……该是多么困难。正是因为这样的高速发展,今日之软件系统无论是规模,还是复杂度,均远远超出过去构建的任何系统。
软件开发者常常陷入与复杂度和规模这些宿敌斗争的泥沼。但正所谓"魔高一尺,道高一丈",无论对手变得多么强大,开发者总能绝处逢生,甚至大获全胜。他们是如何做到的?
一种答案是,软件工程的进展已经与软件规模及复杂度的增长相当。汇编语言编程(assembly language programming)已让位于更高级的语言及结构化编程。在许多领域,过程已让位于对象。软件重用在过去仅仅意味着子例程(subroutine),而现在却代表种类繁多的程序库及框架。
如今,开发者与软件复杂度之间的战争似乎陷入了僵持状态,这并非巧合。由于开发者无法平添智慧,因此转而改良他们的武器。武器的改良给了开发者两种选择:是更容易解决昨日之难题,还是准备与明日之敌作战?尽管我们并不比前辈开发者更加聪明,但是改良了的武器使得我们能够构建规模更大、复杂度更高的软件。
软件开发者总是善于运用一些有形的武器,例如,集成开发环境(integrateddevelopment environments,IDEs)和编程语言,然而,无形的武器带来的影响可以说更为深远。回到篮球比赛的隐喻。假设教练和新手(初出茅庐的新队员)正在观看同一场比赛。教练所能察觉到的内容会远远超过新手。这并非是因为教练火眼金睛,而是因为他掌握了某种无形的武器。通过建立一整套思维抽象,教练能够透过现象看到本质,把对原始现象的感知转换为对目前局势简明扼要的理解。……
物流也快,不错
发货快,没有塑封,这次买了几本用纸箱邮来的,非常好!
非常不错的书
讲的还可以
质量还不错
好评哈哈哈
不错 正品
还没看,希望有帮助
就奖励开开心心
这个商品不错
挺好的一本书
还不错哦,好评!
还没看呢,还行吧
书是好书,质量也还可以,就是当当的服务实在是太差了啊,发货速度慢的要死,然后物流都是交给三方的,签收的时候派了一个不懂怎么使用pos机的人,卡刷了,没有交易单,书的包装简直太环保了,直接裸奔,连基本的塑料皮都没有。
快递员态度很差,可以一星都不给吗
看过在评论
废话太多了,容易抓不住重点,翻译也一般
适合新手。
书经典,送货快递成了慢递,北京发出,三天后才到深圳。
感觉像盗版书,谈架构的,没有一个架构图,或者如何画架构图
翻译应该是没有比这个更烂的,读起来感觉书中的翻译就是挨句用翻译工具翻译的。两句翻译之间的内容可以来个大角度内容转折。这种书看多了语言沟通会出现很严重的障碍。
偏理论些,不过感觉还好了,估计要好长一段时间来消化。。。。。
书是好书, 粗粗读了前四章, 对架构设计做了很好的思考和总结,值得一读。 不过书的封面显得旧了一些。
很不错的一本书,里面讲的挺好的,作者经验很丰富。
过犹不及,不能为设计而设计,为架构而架构,正是“恰如其分”这个词让我决定买它看看
好书。值得仔细阅读的技术书。都是经过多次淘选的。
书送到手之后,包括书页之类的有被人试用过的痕迹,怀疑是二手书
看了两章,看觉很抽象,我还是个初级工程师,但还是很想了解软件架构。
翻译的太差劲了,英文的冗长句子几乎就是原封不动的翻译出来的,本来原版可能是本好书,经这么一翻译简直就是。。。看的人想睡觉。
本书是一本介绍软件架构不可多得的好书,内容详实,结构合理,值得一读。
本书介绍了设计软件架构的方方面面,如何设计一个系统的架构,强调恰如其分而不是过度的设计,主张根据需要不断的演进架构,而不是一开始就设计一个面面俱到的软件架构,这是不现实的。