架构之美(china-pub全国独家首发)(09年度畅销榜TOP50)(全球19位顶尖架构师智慧结晶)(荣获2009年度引进版优秀图书奖)
基本信息
- 原书名: Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design
- 原出版社: O'Reilly Media
- 作者: Diomidis Spinellis Georgios Gousios [作译者介绍]
- 译者: 王海鹏 蔡黄辉 徐锋
- 丛书名: 北京华章图文信息有限公司O'Reilly系列
- 出版社:机械工业出版社
- ISBN:9787111283560
- 上架时间:2009-11-23
- 出版日期:2010 年1月
- 开本:16开
- 页码:366
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 综合
编辑推荐
即日起至2010.6.15日,本书参加买书立减现金活动,详情请查看
Facebook的架构如何建立在以数据为中心的应用生态系统之上.
Xen的创新架构对操作系统未来的影响
KDE项目的社群过程如何让软件的架构从粗略的草图成为漂亮的系统..
蔓延的特征如何让GNU Emacs获得从未想到过的功能
Jikes RVM自优化、自支持的运行时环境背后的魔法...
推荐阅读
内容简介回到顶部↑
健壮、优雅、灵活和易维护的软件架构是怎样炼成的?本书通过一系列优秀的文章回答了这个问题,这些文章来自于十几位当今一流的软件设计师和架构师。在每篇文章中,作者都向我们展示了一个著名的软件架构,并分析了什么让其具有创新性,让其极其符合设计目标。.
本书内容包括:
·facebook的架构如何建立在以数据为中心的应用生态系统之上
·xen的创新架构对操作系统未来的影响
·kde项目的社群过程如何让软件的架构从粗略的草图成为漂亮的系统..
·蔓延的特征如何让gnu emacs获得从未想到过的功能
·jikes rvm自优化、自支持的运行时环境背后的魔法...
本书内容包括:
·facebook的架构如何建立在以数据为中心的应用生态系统之上
·xen的创新架构对操作系统未来的影响
·kde项目的社群过程如何让软件的架构从粗略的草图成为漂亮的系统..
·蔓延的特征如何让gnu emacs获得从未想到过的功能
·jikes rvm自优化、自支持的运行时环境背后的魔法...
作译者回到顶部↑
本书提供作译者介绍
王海鹏 1994年毕业于华东师范大学。拥有理学士(物理)和文学士(英国语言文学)学位。独立的咨询顾问、培训讲师、译者和软件开发者。已翻译十余本软件开发书籍,主题涵盖敏捷方法学、需求工程、UML建模和测试。拥有15年软件开发经验,目前主要的研究领域是软件架构和方法学,致力于提高软件开发的品质和效率。.
蔡黄辉 江苏启东人。1999年毕业于上海交通大学,毕业后一直从事软件开发工作,主要使用Java做Web方面的底层开发。现居住在上海。..
徐锋 中国系统分析员顾问团(CSAI)软件工程首席顾问,.. << 查看详细
蔡黄辉 江苏启东人。1999年毕业于上海交通大学,毕业后一直从事软件开发工作,主要使用Java做Web方面的底层开发。现居住在上海。..
徐锋 中国系统分析员顾问团(CSAI)软件工程首席顾问,.. << 查看详细
目录回到顶部↑
序 .
前言 5
第一部分 论架构
第1章 架构概述 13
1.1 简介 13
1.2 创建软件架构 19
1.3 架构结构 23
1.4 好的架构 27
1.5 美丽的架构 28
致谢 30
参考文献 31
第2章 两个系统的故事:现代软件神话 33
2.1 混乱大都市 34
2.2 设计之城 40
2.3 说明什么问题 47
2.4 轮到你了 48
参考文献 48
第二部分 企业级应用架构
第3章 伸缩性架构设计 51
3.1 简介 51
前言 5
第一部分 论架构
第1章 架构概述 13
1.1 简介 13
1.2 创建软件架构 19
1.3 架构结构 23
1.4 好的架构 27
1.5 美丽的架构 28
致谢 30
参考文献 31
第2章 两个系统的故事:现代软件神话 33
2.1 混乱大都市 34
2.2 设计之城 40
2.3 说明什么问题 47
2.4 轮到你了 48
参考文献 48
第二部分 企业级应用架构
第3章 伸缩性架构设计 51
3.1 简介 51
译者序回到顶部↑
人们在生活和工作中发现美并创造美,软件开发和架构设计也不例外。架构之美体现了关注点的分离与结合。在软件设计中,设计师需要考虑多方面的关注点。.
漂亮的架构设计让这些关注点尽可能分离,然后以最简单的机制结合在一起,从而得到高内聚、低耦合的系统。例如在Darkstar项目中,架构师们考虑的重点就是如何将多人在线游戏的游戏逻辑与系统的可伸缩性分离开来,让游戏的开发者只要遵守少量的规则,就能够像编写单机游戏一样编写大规模多人在线游戏。又如REST架构风格,体现了对资源命名、请求处理和资源物理表现形式的关注点分离。资源的名称与请求资源时服务器的处理方式无关,请求者无需知道服务器端采取的技术,并且请求者本来就不关心服务器端的处理技术。资源的物理表示形式可以通过内容协商来决定,使系统可以支持多种物理表示形式,并可以方便地扩展。
架构之美注重表达的简洁性。“Don’tRepeat Yourself”,好的架构致力于消除各种类型的信息重复。从结构化程序设计中的子程序和函数,到面向对象程序设计中的继承,无不体现了对表达简洁性的特殊偏爱。在敏捷方法学中,消除重复则是重构的主要目的之一。爱因斯坦说:“让它尽可能简单,但不要过于简单。”我们需要考虑所有必须考虑的关注点,然后用简洁漂亮的架构体现我们的关注。同时,简洁的架构之美也降低了软件的总体成本,从这个意义上说,“简洁性”又可以称为“经济性”。..
架构之美需要解决实际问题,它既是艺术,也是生活。软件像建筑一样,它的美不能脱离它的实用价值。Bjarne Stroustrup说,人类文明运行于软件之上。每一个软件都有自己的架构,这些架构有的很美,有的不太美。从艺术的角度来说,美是创造矛盾并解决矛盾。架构的多关注点和表达简洁性就是一种矛盾,美丽的架构提供了这一矛盾的解决方法,让我们的内心产生一种愉快的感觉。
架构之美需要经过专业的学习才能更好地欣赏和创造。和所有的艺术之美一样,不是说不经过专业学习就不能欣赏,但是经过了专业的学习,就能更好地欣赏这种美的种种精妙之处。如果想要创造出这种美,那就必然要经过长期的专业学习。
架构之美经过时间打磨。像Facebook面向数据的Web服务、FQL和FML架构,是在对应不同实际需求的过程中逐渐发展起来。在应用程序架构形成的过程中,设计者不断面对新的关注点需求,不断对已有的架构进行修改,并发展出新的架构组件。这就是所谓的“演进式架构”。只有变化是永恒不变的。在架构设计初期,设计者会将一些关注点有意推迟到将来考虑,例如持久和并发。对于这些暂不考虑的关注点,设计者对它们的实现方式尽可能不做任何假定,从而保留更多的可能性,让不同关注点之间的耦合尽可能小。架构之美没有定法。虽然有一些法则可供我们参考,却没有非如此不可的。《金刚经》云:“一切贤圣,皆以无为法而有差别。”
参加本书翻译工作的人员还有蔡黄辉、徐锋、王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。
在这本书的翻译过程中,我受益良多,因此郑重地向大家推荐它。...
漂亮的架构设计让这些关注点尽可能分离,然后以最简单的机制结合在一起,从而得到高内聚、低耦合的系统。例如在Darkstar项目中,架构师们考虑的重点就是如何将多人在线游戏的游戏逻辑与系统的可伸缩性分离开来,让游戏的开发者只要遵守少量的规则,就能够像编写单机游戏一样编写大规模多人在线游戏。又如REST架构风格,体现了对资源命名、请求处理和资源物理表现形式的关注点分离。资源的名称与请求资源时服务器的处理方式无关,请求者无需知道服务器端采取的技术,并且请求者本来就不关心服务器端的处理技术。资源的物理表示形式可以通过内容协商来决定,使系统可以支持多种物理表示形式,并可以方便地扩展。
架构之美注重表达的简洁性。“Don’tRepeat Yourself”,好的架构致力于消除各种类型的信息重复。从结构化程序设计中的子程序和函数,到面向对象程序设计中的继承,无不体现了对表达简洁性的特殊偏爱。在敏捷方法学中,消除重复则是重构的主要目的之一。爱因斯坦说:“让它尽可能简单,但不要过于简单。”我们需要考虑所有必须考虑的关注点,然后用简洁漂亮的架构体现我们的关注。同时,简洁的架构之美也降低了软件的总体成本,从这个意义上说,“简洁性”又可以称为“经济性”。..
架构之美需要解决实际问题,它既是艺术,也是生活。软件像建筑一样,它的美不能脱离它的实用价值。Bjarne Stroustrup说,人类文明运行于软件之上。每一个软件都有自己的架构,这些架构有的很美,有的不太美。从艺术的角度来说,美是创造矛盾并解决矛盾。架构的多关注点和表达简洁性就是一种矛盾,美丽的架构提供了这一矛盾的解决方法,让我们的内心产生一种愉快的感觉。
架构之美需要经过专业的学习才能更好地欣赏和创造。和所有的艺术之美一样,不是说不经过专业学习就不能欣赏,但是经过了专业的学习,就能更好地欣赏这种美的种种精妙之处。如果想要创造出这种美,那就必然要经过长期的专业学习。
架构之美经过时间打磨。像Facebook面向数据的Web服务、FQL和FML架构,是在对应不同实际需求的过程中逐渐发展起来。在应用程序架构形成的过程中,设计者不断面对新的关注点需求,不断对已有的架构进行修改,并发展出新的架构组件。这就是所谓的“演进式架构”。只有变化是永恒不变的。在架构设计初期,设计者会将一些关注点有意推迟到将来考虑,例如持久和并发。对于这些暂不考虑的关注点,设计者对它们的实现方式尽可能不做任何假定,从而保留更多的可能性,让不同关注点之间的耦合尽可能小。架构之美没有定法。虽然有一些法则可供我们参考,却没有非如此不可的。《金刚经》云:“一切贤圣,皆以无为法而有差别。”
参加本书翻译工作的人员还有蔡黄辉、徐锋、王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。
在这本书的翻译过程中,我受益良多,因此郑重地向大家推荐它。...
前言回到顶部↑
出版本书的想法是在2007年确立的,它是获奖的畅销书《Beautiful Code》(编辑注)的姊妹篇。在这本书中,虽然范围和目的不一样,但关注点是类似的:让最优秀的设计师和架构师来描述他们所选的软件架构,剥开他们作品的各层,展示他们如何让软件实现功能性、可靠性、易用性、高效率、可维护性、可移植性,当然,还有优雅性。.
为了编成这本书,我们联系了一些著名软件项目的主要架构师和一些不太著名但高度创新的软件项目的主要架构师。许多人快速回应,将引人思索的想法寄回给我们。有些想法甚至让我们大吃一惊,他们建议不要写具体的系统,而是调查架构在软件工程中产生影响的深度和广度。
当本书的所有作者听说这本书的版税将捐给Medecins Sans Frontieres(无国界医生组织)时,都感到十分高兴。Medecins Sans Frontieres是一个国际人道主义援助组织,为困难的人提供紧急医疗救助。
本书的组织
我们围绕5个主题领域来组织本书的内容:概述、企业应用、系统、最终用户应用和编程语言。很明显,缺少有关桌面软件架构的章节,但这不是故意的。我们联系了50多位软件架构师,这个结果让我们吃惊不小。难道真的没有美丽桌面软件架构的漂亮例子吗?或者那些天才的架构师避而不谈架构,是因为忙着应付需求,为应用堆彻更多的功能?我们非常期望听听你对于这些问题的见解。
第一部分:论架构
本书的第一部分探讨了软件架构的广度和范围,以及它对软件的开发和演进意味着什么。
第1章由JohnKlein和DavidWeiss编写,他们从架构的品质考虑和架构结构的角度,对架构进行了探讨。
第2章由Pete Goodliffe编写,他写了一篇寓言,揭示了软件架构如何影响系统的演进和开发者在项目中的参与情况。
第二部分:企业级应用架构
企业级系统是许多组织机构的IT支柱,它们不仅巨大,而且常常是度身定制的软件集,一般由许多分散的组件构成。它们服务于大量的、支持事务的工作,必须延伸到它们所支持的企业的各个角落,时刻准备着适应不断变化的业务需求。在为这样的系统设计架构时,可伸缩性、正确性、稳定性和可扩展性是最重要的关注点。本书的第二部分包含了一些企业级软件架构的优秀范例。
第3章由JimWaldo编写,展示了构建大规模多人在线游戏所需的架构技术。
第4章由MichaelNygard编写,介绍了一个多阶段、多地点的数据处理系统的架构,展示了让系统能工作所必需的折中。
第5章由Brian Sletten编写,讨论了创建数据驱动的应用时资源映射的威力,提供了纯面向资源架构的一个优雅的例子。
第6章由DaveFetterman编写,他提倡以数据为中心的系统,解释了好的架构如何能够创造并支持应用生态系统。..
第三部分:系统架构
系统软件可能是在设计方面要求最高的软件,部分原因是因为高效率地使用硬件是少数人才能掌握的神秘艺术,还有部分原因是因为许多人认为系统软件的架构是理所当然的存在。了不起的系统架构很少是从一张白纸开始的,我们今天使用的大多数系统是基于20世纪60年代的设想。第三部分的这几章介绍了4种创新的系统架构,讨论了架构决定背后的复杂性,这正是它们美丽的原因。
第7章由DerekMurray和KeirFraser编写,提供了一个例子说明深思熟虑的架构如何能够改变操作系统演进的方式。
第8章由GregLehey编写,回顾了Tandem的架构选择和组成部分(包括硬件和软件),正是这些让Tandem成为近二十年的高可用性环境的首选平台。
第9章由Rhys Newman和ChristopherDennis编写,描述了如何通过小心地设计软件和很好地理解领域需求来克服编程系统中那些可以察觉到的不足。
为了编成这本书,我们联系了一些著名软件项目的主要架构师和一些不太著名但高度创新的软件项目的主要架构师。许多人快速回应,将引人思索的想法寄回给我们。有些想法甚至让我们大吃一惊,他们建议不要写具体的系统,而是调查架构在软件工程中产生影响的深度和广度。
当本书的所有作者听说这本书的版税将捐给Medecins Sans Frontieres(无国界医生组织)时,都感到十分高兴。Medecins Sans Frontieres是一个国际人道主义援助组织,为困难的人提供紧急医疗救助。
本书的组织
我们围绕5个主题领域来组织本书的内容:概述、企业应用、系统、最终用户应用和编程语言。很明显,缺少有关桌面软件架构的章节,但这不是故意的。我们联系了50多位软件架构师,这个结果让我们吃惊不小。难道真的没有美丽桌面软件架构的漂亮例子吗?或者那些天才的架构师避而不谈架构,是因为忙着应付需求,为应用堆彻更多的功能?我们非常期望听听你对于这些问题的见解。
第一部分:论架构
本书的第一部分探讨了软件架构的广度和范围,以及它对软件的开发和演进意味着什么。
第1章由JohnKlein和DavidWeiss编写,他们从架构的品质考虑和架构结构的角度,对架构进行了探讨。
第2章由Pete Goodliffe编写,他写了一篇寓言,揭示了软件架构如何影响系统的演进和开发者在项目中的参与情况。
第二部分:企业级应用架构
企业级系统是许多组织机构的IT支柱,它们不仅巨大,而且常常是度身定制的软件集,一般由许多分散的组件构成。它们服务于大量的、支持事务的工作,必须延伸到它们所支持的企业的各个角落,时刻准备着适应不断变化的业务需求。在为这样的系统设计架构时,可伸缩性、正确性、稳定性和可扩展性是最重要的关注点。本书的第二部分包含了一些企业级软件架构的优秀范例。
第3章由JimWaldo编写,展示了构建大规模多人在线游戏所需的架构技术。
第4章由MichaelNygard编写,介绍了一个多阶段、多地点的数据处理系统的架构,展示了让系统能工作所必需的折中。
第5章由Brian Sletten编写,讨论了创建数据驱动的应用时资源映射的威力,提供了纯面向资源架构的一个优雅的例子。
第6章由DaveFetterman编写,他提倡以数据为中心的系统,解释了好的架构如何能够创造并支持应用生态系统。..
第三部分:系统架构
系统软件可能是在设计方面要求最高的软件,部分原因是因为高效率地使用硬件是少数人才能掌握的神秘艺术,还有部分原因是因为许多人认为系统软件的架构是理所当然的存在。了不起的系统架构很少是从一张白纸开始的,我们今天使用的大多数系统是基于20世纪60年代的设想。第三部分的这几章介绍了4种创新的系统架构,讨论了架构决定背后的复杂性,这正是它们美丽的原因。
第7章由DerekMurray和KeirFraser编写,提供了一个例子说明深思熟虑的架构如何能够改变操作系统演进的方式。
第8章由GregLehey编写,回顾了Tandem的架构选择和组成部分(包括硬件和软件),正是这些让Tandem成为近二十年的高可用性环境的首选平台。
第9章由Rhys Newman和ChristopherDennis编写,描述了如何通过小心地设计软件和很好地理解领域需求来克服编程系统中那些可以察觉到的不足。
序言回到顶部↑
推荐序一
如何看到一滴水的美丽
支付宝(中国)公司业务架构师
《大道至简》作者周爱民(aimingoo)
【一】
架构是一个过程,而非一个结果。
【二】
在大多数人的谈论中,架构是一个目标产物,而作为架构师的责任就是去生产它。所以无论如何,架构是可以“做”出来的,而且也应该有一些“做”的方法、技术、技巧。
有人问过我:架构的最主要产出是什么?我的答案是:图。这里面有两层含义:一层含义是如同建筑师描绘的蓝图一样,用于引导实施者;另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像,他是没有办法把它画出来的。
【三】
画家画的无非是物我。画物的画家,最终画的还是我见。所以,画家的笔最终描绘的是他自己心里的映像。
【四】
艺术是不可能被“生产”出来的,生产出来的,叫“艺术品”。
【五】
架构这个过程,是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的(例如作为系统中的任何一个角色),只有清晰地理解系统,才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候,架构这一过程就已经结束了。
【六】
一滴水滴落的过程中,有多少个形态的变化?
如何看到一滴水的美丽
支付宝(中国)公司业务架构师
《大道至简》作者周爱民(aimingoo)
【一】
架构是一个过程,而非一个结果。
【二】
在大多数人的谈论中,架构是一个目标产物,而作为架构师的责任就是去生产它。所以无论如何,架构是可以“做”出来的,而且也应该有一些“做”的方法、技术、技巧。
有人问过我:架构的最主要产出是什么?我的答案是:图。这里面有两层含义:一层含义是如同建筑师描绘的蓝图一样,用于引导实施者;另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像,他是没有办法把它画出来的。
【三】
画家画的无非是物我。画物的画家,最终画的还是我见。所以,画家的笔最终描绘的是他自己心里的映像。
【四】
艺术是不可能被“生产”出来的,生产出来的,叫“艺术品”。
【五】
架构这个过程,是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的(例如作为系统中的任何一个角色),只有清晰地理解系统,才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候,架构这一过程就已经结束了。
【六】
一滴水滴落的过程中,有多少个形态的变化?
媒体评论回到顶部↑
“这本书的作者们在介绍软件架构的基本实践和最佳实践方面干得很漂亮,他们也同样漂亮地介绍了各式各样的现代系统。我特别喜欢他们谈及的架构的广泛性,从Emacs到Facebook,从非常正式的系统到非常有灵气的系统。
简而言之,这是一本非常及时的书,对于软件架构的艺术、科学和实践是非常有益的贡献。”
-- Grady Booch,IBM院士...
简而言之,这是一本非常及时的书,对于软件架构的艺术、科学和实践是非常有益的贡献。”
-- Grady Booch,IBM院士...
【插图】


点击看大图
















加载中...
