架构实战

出版者:机械工业出版社

作者:[英] Peter Eeles

页数:241

译者:蔡黄辉

出版时间:2010-5

价格:45.00元

装帧:平装

isbn号码:9787111301158

具体描述

本书从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如 何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件开发项目可能 存在的困难及相应的处理方法。

本书理论结合实践，介绍了一些可以应用到整个或部分的架构设计流程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅 读本书都能从中获益。

作者简介

Peter Eeles，IBM Rational Software的高级IT架构师，其主要工作室进行架构设计和实现大规模、分布式的系统。他目前致力于帮助组织提高软件开发能力。除本书外，Eeles还与人合作编写了《Building J2EETM Applications with the Rational Unified Process》（Addison-Wesley，2003）和《Building Business Objects》（Wiley，1998）。

Peter Cripps，IBM Global Business Services的高级IT架构师，专注于应用组件和基于服务的开发技术，并在整个IBM公司推广架构设计最佳实践，目前从事IBM Unified Method Framework的开发工作。

目录信息

译者序序前言致谢作者简介第1章 导言 1.1 流程应用 1.2 流程概述 1.3 范围 1.4 总结第2章 架构、架构师和架构设计 2.1 架构 2.1.1 架构定义结构 2.1.2 架构定义行为 2.1.3 架构关注重要的元素 2.1.4 架构平衡利益相关者的需要 2.1.5 架构基于合理证据使决策具体化 2.1.6 架构会遵循一种架构风格 2.1.7 架构受它的环境影响 2.1.8 架构影响开发团队的结构 2.1.9 所有系统都存在架构 2.1.10 架构有特定的范围 2.2 架构师 2.2.1 架构师是技术领导 2.2.2 架构师的角色可能由一个团队来履行 2.2.3 架构师理解软件开发流程 2.2.4 架构师掌握业务领域的知识 2.2.5 架构师掌握技术知识 2.2.6 架构师掌握设计技能 2.2.7 架构师具备编程技能 2.2.8 架构师是优秀的沟通人员 2.2.9 架构师进行决策 2.2.10 架构师知道组织政策 2.2.11 架构师是谈判专家 2.3 架构设计 2.3.1 架构设计是一门科学 2.3.2 架构设计是一门艺术 2.3.3 架构设计跨越很多方面 2.3.4 架构设计是一个渐进的活动 2.3.5 架构设计受许多利益相关者驱动 2.3.6 架构设计经常包括折中 2.3.7 架构设计承认经验 2.3.8 架构设计既由上而下也由下而上 2.4 架构设计的优点 2.4.1 架构设计解决系统的质量问题 2.4.2 架构设计促进达成共识 2.4.3 架构设计支持计划编制流程 2.4.4 架构设计促进架构的完整性 2.4.5 架构设计有助于管理复杂性 2.4.6 架构设计为重用提供基础 2.4.7 架构设计降低维护成本 2.4.8 架构设计支持影响分析 2.5 总结第3章 方法基本原理 3.1 关键概念 3.2 方法内容 3.2.1 角色 3.2.2 工作产品 3.2.3 活动 3.2.4 任务 3.3 流程 3.3.1 瀑布流程 3.3.2 迭代流程 3.3.3 敏捷流程 3.4 总结第4章 编写软件架构文档 4.1 最终的结局 4.2 关键概念 4.3 视点和视图 4.3.1 基础视点 4.3.2 交叉视点 4.3.3 视图及图表 4.3.4 视点及视图的优点 4.4 模型 4.4.1 实现的层级 4.4.2 模型的优点 4.5架构描述框架的特征 4.5.1 软件架构的4+1视图模型 4.5.2 Zachman框架 4.5.3 Rozanski和Woods框架 4.6 一个架构描述框架 4.6.1 视点 4.6.2 工作产品 4.6.3 实现的层级 4.6.4 视图一致 4.7 软件架构文档 4.8 总结第5章 可重用架构资源 5.1 架构的来源 5.2 架构资源元模型 5.2.1 开发期资源 5.2.2 运行期资源 5.3 资源类型 5.3.1 参考架构 5.3.2 开发方法 5.3.3 视点目录 5.3.4 架构风格 5.3.5 架构机制 5.3.6 模式 5.3.7 参考模型 5.3.8 架构决策 5.3.9 现有的应用程序 5.3.10 封装的应用程序 5.3.11 应用框架 5.3.12 组件库/组件 5.4 架构资源的属性 5.5 重用的其他考虑因素 5.6 总结第6章 案例介绍 6.1 流程应用 6.2 案例研究范围 6.2.1 项目团队 6.2.2 外部影响因素 6.3 应用简介 6.4 YoreTour的愿景 6.4.1 问题声明 6.4.2 利益相关者 6.4.3 系统功能 6.4.4 系统的质量 6.4.5 约束 6.5 总结第7章 定义需求 7.1 关联需求和架构 7.2 功能性需求和非功能性需求 7.3 编写需求文档的技术 7.4 流程应用 7.5 理解任务描述 7.6 定义需求：活动概览 7.7 总结第8章 创建逻辑架构 8.1 从需求走向解决方案 8.2 逻辑架构的价值 8.2.1 使逻辑架构最小化 8.2.2 把逻辑架构作为一项投资 8.2.3 可追溯性的重要性 8.3 流程应用 8.4 创建逻辑架构：活动概览 8.5 总结第9章 创建物理架构 9.1 从逻辑架构到物理架构 9.2 流程应用 9.3 创建物理架构：活动概览 9.4 任务：调查架构资源 9.5 任务：定义架构概览 9.6 任务：编写架构决策文档 9.7 任务：概述功能性元素 9.7.1 将逻辑功能元素映射到物理功能元素 9.7.2 确认物理功能元素 9.7.3 采购产品 9.7.4 适应特定技术的模式 9.8 任务：概述部署元素 9.8.1 映射逻辑部署元素到物理部署元素 9.8.2 确认物理部署元素 9.8.3 采购硬件 9.9 任务：检验架构 9.10 任务：构建架构概念证明 9.11 任务：细化功能性元素 9.12 任务：细化部署元素 9.13 任务：确认架构 9.14 任务：更新软件架构文档 9.15 任务：和利益相关者复审架构 9.16 总结第10章 进阶 10.1 架构师和项目团队 10.1.1 架构师和需求 10.1.2 架构师和开发 10.1.3 架构师和测试 10.1.4 架构师和项目管理 10.1.5 架构师和配置管理 10.1.6 架构师和变更管理 10.1.7 架构师和开发环境 10.1.8 架构师和业务分析 10.2 架构师和外界影响 10.2.1 企业架构 10.2.2 设计权威 10.2.3 基础设施提供者 10.2.4 系统维护者 10.3 复杂系统的架构设计 10.3.1 许多独特的功能正在开发 10.3.2 许多人员参与开发 10.3.3 系统是高度分布式的 10.3.4 开发团队是分布式的 10.3.5 运行质量非常有挑战性 10.3.6 存在系统之系统 10.4 总结附录A 软件架构元模型附录B 视点目录附录C 方法概述附录D 架构需求检查列表术语表参考文献
· · · · · · (收起)

读后感

最早接触软件架构方面的内容是在“软件工程”的课程之中，当时只是觉得遥不可即。教师缺乏开发经验更导致这种实践指导思想难以贯彻，终于不了了之。但是当我在做平生第一个“大”程序时，问题出现了。由于对软件架构规划不甚了了，最初我对它是没什么规划的，不知不觉就...  

就像本书开题引用Bjarne Stroustrup所说“我们的文明建立在软件之上”一样，软件给我们带来的影响远远超出了我们的想象。可以说当今的生活点点滴滴都离不开软件，从而产生了软件架构之说。软件架构师的重要性也就不言而喻了。其实在我们编写程序之初也一直在追寻这犹如海市蜃楼...  

众所周知，IBM里面的人都是是螺丝钉型专家，本身就像软件里的模块，接受一些输入，产生一些输出，随时可以被替换。 架构师如果不写代码，那么他的工作成果体现在哪呢？大概就是文档和各种各样的结构图 对于当今互联网企业来说，需要的是多面手，尤其对于中小企业，不太可能养活...  

以前对软件架构方面的内容稍微有点了解，从大学里的《软件工程》课程、以及在网络上的零星文章中。 上学时，我们所学到的知识大多为一些基础的理论知识。以前也从未想过要深入了解软件架构，如今华章引进并出版了Peter Eeles与 Peter Cripps在软件架构方面的名著《架构实战—软...  

上周收到了《架构实战-软件架构设计的过程》的样书。在此，先感谢下中国XML论坛提供的参与机会，也感谢主办方华章出版社。 这本书并不厚，甚至可以说有点薄。但是，它恰到好处。 记得大学快毕业那会儿，由于我是做Web开发的，所以，对互联网信息的爆炸有自己的看法，如何帮助...  

用户评价

我常常觉得，很多技术书籍读起来就像是在啃一块干瘪的木头，信息量巨大，但缺乏“滋味”。然而，这本书却像是一场精心烹制的盛宴，知识点被巧妙地穿插在引人入胜的场景描述中。它最让我震撼的是对“非功能性需求”的深刻洞察。很多初级或中级工程师在设计系统时，往往只关注功能的实现，而忽略了性能、可维护性和弹性这些“隐形杀手”。这本书则用大量的篇幅，详尽地阐述了如何将这些需求融入到架构设计的早期阶段。比如，在讨论数据一致性时，它不仅仅停留在CAP理论的表面，而是结合了实际的分布式事务处理框架，比如Saga模式的优劣势，以及如何在保证用户体验的前提下进行最终一致性的取舍。这使得整本书的基调非常“接地气”。它不是一本高高在上的学术论文集，而更像是一位资深专家坐在你旁边，跟你分享他多年来踩过的“坑”和总结出的“宝典”。我甚至能想象到作者在写这些内容时，是如何反复权衡着“清晰度”与“深度”之间的微妙平衡。这种细腻的笔触，让读者在学习新知识的同时，也能感受到一种久经沙场的沉稳。

这本书的叙事节奏把握得相当到位，作者仿佛是一位经验老到的建筑师，手里拿着蓝图，一步步引导我们走进那个充满挑战与创新的领域。我特别欣赏它在理论与实践之间的巧妙平衡。它没有陷入空泛的理论说教，而是通过一系列精心设计的案例，将那些晦涩难懂的概念变得触手可及。例如，书中对微服务架构演进路径的剖析，简直像是一部微缩的历史纪录片，从最初的单体困境到最终的分布式优化，每一步的权衡与取舍都描绘得淋漓尽致。读完相关的章节，我立刻能联想到自己项目中遇到的瓶颈，那些曾经模糊的解决方案，现在似乎都有了清晰的脉络可以遵循。更难能可贵的是，作者对不同技术选型的优缺点进行了深入的对比分析，不偏袒任何一方，而是基于具体的业务场景给出最合理的建议。这种客观、审慎的态度，对于我们这些在实际工作中摸爬滚打的工程师来说，无疑是极大的福音。它教会我的不仅是如何搭建系统，更是如何像一个架构师那样去思考决策的优先级和长远影响。这本书的排版和图示也做得非常专业，那些结构图和流程图清晰地勾勒出了复杂的系统蓝图，极大地降低了阅读的认知负荷。

这本书的结构安排体现了极高的逻辑性，它仿佛构建了一个从宏观到微观，再到回溯优化的完整闭环。我最欣赏它处理“技术选型与业务解耦”这一对矛盾时的处理方式。许多架构师在实践中会陷入“为了架构而架构”的误区，盲目引入最新的技术栈，结果导致运维成本急剧上升，业务方反而抱怨系统复杂难懂。这本书则非常清醒地指出，架构的本质是服务于业务。它详细阐述了如何通过领域驱动设计（DDD）的边界上下文划分，来指导技术边界的划分，确保每一层架构的变动都是有清晰的业务驱动力的。这种自上而下的设计思维贯穿始终，让读者能够清晰地看到技术决策是如何与企业的长期战略目标对齐的。书中还穿插了一些关于“架构师影响力”的探讨，比如如何有效地向非技术背景的管理者阐述复杂架构的价值和风险，这绝对是教科书上很少涉及但至关重要的实践技能。这些“软技能”的融入，让整本书的实用价值大大提升，它不再仅仅是一本技术手册，更像是一本架构师的生存指南。

阅读体验方面，这本书给我带来了极大的惊喜。通常情况下，技术书籍的行文风格往往偏向于冷峻和刻板，让人难以产生共鸣。但此书的语言风格充满了活力和一种知识分子的幽默感。它在关键概念的引入处，经常会设置一些富有启发性的反问句或者类比，瞬间将读者的注意力从纷繁的代码细节中抽离出来，提升到战略层面进行思考。例如，在描述如何处理“依赖爆炸”问题时，作者用了一个非常形象的比喻，将紧耦合的模块比作“七手八脚的连环锁”，一旦其中一个环节出错，整个系统都会陷入瘫痪。这种生动的描绘，远比枯燥的定义要有效得多。此外，书中的每一章末尾都设置了“架构师的自省”环节，这不仅仅是知识点的复习，更像是一种方法论的提炼。它引导读者去反思自己的设计思路是否过度工程化，或者是否为了追求时髦的技术而牺牲了系统的简洁性。这种注重“思维模式”而非“工具集”的培养方式，我认为是区分优秀技术书籍和平庸之作的关键所在。它塑造的不是一个工具的使用者，而是一个系统的思考者。

对于那些渴望从“实现者”蜕变为“设计者”的工程师来说，这本书简直是打开了一扇通往新世界的大门。它最独特的一点在于对“架构债务”的管理和偿还策略的探讨。很多系统设计书籍只关注如何“建”，却很少提及如何“修补”和“迭代”。而这本书则非常坦诚地剖析了技术债务的形成机制——往往不是因为偷懒，而是因为早期信息不足导致的必然结果。随后，它提供了一套系统化的评估和清理架构债务的框架，包括如何量化债务的成本，以及如何与产品经理协商优先级来逐步重构。这种对系统生命周期的全面掌控感，是其他同类书籍中罕见的。特别是书中关于“渐进式架构演进”的章节，避免了那种动辄“推倒重来”的激进路线，而是主张“小步快跑”的风险控制策略，这在现实企业的预算和时间限制下，具有极强的指导意义。读罢全书，我感觉自己的视野被极大地拓宽了，不再仅仅关注代码的实现效率，而是开始关注整个技术生态的健康度和长远的适应性。这本书确实能帮助读者建立起一种全面、成熟的系统观。

咋一看还以为是O'rielly的Theory In Practice系列。。才发现被坑了啊。。

不知所云

咋一看还以为是O'rielly的Theory In Practice系列。。才发现被坑了啊。。

IBM架构师的实践

翻译的书籍的通病，较为生硬；既然是实践，这本书讲的过程方法论