作者简介
作者:(印)蒂拉克·米特拉 译者:爱飞翔
Tilak Mitra，IBM全球企业咨询服务部首席技术官(CTO)。他是lBM杰出工程师，在lT界拥有超过18年的专业经验，主要关注复杂系统的设计、企业架构、应用分析与优化等技术，并致力于将这些技术运用到工业制造、自动化、工程学及相关领域中。他是一位有影响力的技术专家和战略专家，也是一位颇受好评的意见领袖，他在IBM所引领和推动的跨学科创新活动受到了很多人的欢迎。爱飞翔,资深软件开发工程师，擅长Web开发、移动开发和游戏开发，有10余年开发经验，曾主导和参与了多个手机游戏和手机软件项目的开发，经验十分丰富。业余爱好文学和历史，有一定的文学造诣。翻译并出版了《Android游戏开发实践指南》《测试驱动的iOS开发》《HTML5Canvas核心技术：图形、动画与游戏开发》《NoSQL精粹》和《JavaScript应用开发实践指南》等书。
目录
目录
题献
译者序
序
前言
致谢
第1章 案例研究1
1.1 业务问题1
1.1.1 技术挑战2
1.1.2 用例2
1.1.3 在机器运转过程中进行实时处理与监控3
1.1.4 为新机器提供无缝的激活服务3
1.1.5 生成工作定单3
1.1.6 尽量减少在为全球客户提供服务时所产生的延迟4
1.2 小结4
第2章 软件架构是什么？为什么需要做软件架构6
2.1 背景知识6
2.2 软件架构是什么7
2.3 为什么需要做软件架构9
2.3.1 把架构视为交流工具9
2.3.2 对项目规划施加影响力10
2.3.3 关注非功能方面的能力11
2.3.4 与设计团队和实现团队做出约定12
2.3.5 为影响力分析提供支持12
2.4 架构视图与架构视点13
2.5 小结16
2.6 参考资料16
第3章 恰到好处地把握架构中的重要方面17
3.1 软件架构中需要关注的一些方面17
3.2 小结19
第4章 系统环境20
4.1 业务环境与系统环境之间的辨析20
4.2 捕获系统环境22
4.2.1 系统环境图23
4.2.2 信息流25
4.3 案例研究：Elixir的系统环境27
4.3.1 Elixir的系统环境图27
4.3.2 Elixir的信息流32
4.4 小结33
4.5 参考资料33
第5章 架构概述34
5.1 什么是架构概述34
5.2 为什么要做架构概述36
5.3 企业视图37
5.3.1 用户与传输渠道39
5.3.2 核心业务流程39
5.3.3 数据与信息40
5.3.4 技术推动力41
5.4 分层视图42
5.4.1 第1层：操作层45
5.4.2 第2层：服务组件层45
5.4.3 第3层：服务层45
5.4.4 第4层：业务流程层46
5.4.5 第5层：消费者层46
5.4.6 第6层：集成层46
5.4.7 第7层：QoS层46
5.4.8 第8层：信息架构层47
5.4.9 第9层：治理层47
5.4.10 进一步研究分层视图的用法47
5.5 IT系统视图48
5.6 案例研究：Elixir的架构概述53
5.6.1 Elixir的企业视图53
5.6.2 Elixir的业务流程54
5.6.3 Elixir的数据及信息54
5.6.4 Elixir的技术推动力55
5.6.5 Elixir的分层视图56
5.6.6 Elixir的IT系统视图57
5.7 小结58
5.8 参考资料59
第6章 架构决策60
6.1 为什么需要做架构决策60
6.2 怎样开始进行架构决策61
6.3 创建架构决策62
6.4 案例研究：Elixir的架构决策67
6.5 小结69
第7章 功能模型71
7.1 为什么需要功能模型71
7.2 可追溯性73
7.3 制定功能模型74
7.3.1 逻辑层面的设计75
7.3.2 规格层面的设计79
7.3.3 物理层面的设计89
7.4 案例研究：Elixir的功能模型91
7.4.1 逻辑层面92
7.4.2 规格层面94
7.4.3 物理层面97
7.5 小结98
7.6 参考资料99
第8章 操作模型100
8.1 为什么需要操作模型101
8.2 可追溯性与服务级别协议102
8.3 制定操作模型104
8.3.1 概念操作模型105
8.3.2 规格操作模型116
8.3.3 物理操作模型122
8.4 案例研究：Elixir的操作模型132
8.4.1 COM132
8.4.2 SOM137
8.4.3 POM138
8.5 小结140
8.6 参考资料141
第9章 集成：方式与模式142
9.1 为什么需要进行集成142
9.2 集成方式143
9.2.1 用户界面的集成144
9.2.2 数据层面的集成144
9.2.3 消息层面的集成147
9.2.4 API层面的集成149
9.2.5 服务层面的集成150
9.3 集成模式152
9.3.1 同步的请求栂煊δＪ?152
9.3.2 批次模式153
9.3.3 同步的批次请求栍Υ鹉Ｊ?153
9.3.4 异步的批次请求栍Υ鹉Ｊ?153
9.3.5 存储并转发模式154
9.3.6 发布柖┰哪Ｊ?154
9.3.7 聚合模式154
9.3.8 管道与过滤器模式155
9.3.9 消息路由器模式155
9.3.10 消息转换器模式156
9.4 案例研究：Elixir的集成视图156
9.4.1 标签1～5所表示的数据流157
9.4.2 标签6～8所表示的数据流158
9.4.3 标签9～10所表示的数据流158
9.4.4 标签11～12所表示的数据流158
9.5 小结159
9.6 参考资料160
第10章 基础设施问题161
10.1 为什么要把基础设施做好162
10.2 需要考虑的基础设施问题162
10.2.1 网络163
10.2.2 托管165
10.2.3 高可用性与容错性169
10.2.4 灾难恢复178
10.2.5 能力规划178
10.3 案例研究：Elixir系统的基础设施问题181
10.4 小结183
10.5 我们现在讲到什么地方了184
10.6 参考资料186
第11章 分析架构入门187
11.1 为什么要做分析188
11.2 进行数据分析所采用的维度189
11.2.1 操作分析189
11.2.2 描述性的分析190
11.2.3 预测性的分析190
11.2.4 指示性的分析191
11.2.5 认知计算192
11.3 分析架构的基础194
11.3.1 分层视图中的各层及五大支柱195
11.3.2 水平层196
11.3.3 垂直层199
11.3.
序言
序软件架构这个词，有些人听了觉得开心，有些人听了要皱眉头，而更多的人对它漠不关心，尤其是那些整天忙着敲代码，没时间思考设计问题的人。
我们知道，软件密集型的系统都是有架构的。有一些架构是刻意而为的，有一些架构是偶然浮现出来的，还有很多架构隐藏在成千上万个小的设计决策中，而这些设计决策，正源于我们敲出来的那些代码。
Tilak先生在本书中精彩地讲解了一些切实可行而且非常实用的方式与方法，以帮助我们架构出复杂的系统。作者是一位拥有实际经验的架构师，他通过一系列案例研究，解释了“架构是什么”以及“架构不是什么”这两个问题，同时还讲解了在软件密集型的系统中，如何使架构成为开发、交付及部署过程的一部分。如果大家了解我，那一定知道我对软件架构这个主题有一些强烈的个人观点，然而在我读过的关于这个主题的那么多本书和那么多篇文章中，我确实觉得Tilak所说的这套方法是建立在坚实的基础之上的，而且他的方法特别容易理解，也特别容易施行。
软件架构并不是一项纯粹的技术，其中还要考虑人的因素。本书正是抓住了这个重要的因素—Tilak把自己在架构工作中汲取的经验教训合理地穿插在本书中，我很欣赏这一点。
架构是个重要的过程，这个过程不仅不能妨碍系统的构建，而且还必须在恰当的时机以合适的资源和特别实用的方式构建出正确的系统。
Grady BoochIBM院士及软件工程首席科学家
作者:(印)蒂拉克·米特拉 译者:爱飞翔
Tilak Mitra，IBM全球企业咨询服务部首席技术官(CTO)。他是lBM杰出工程师，在lT界拥有超过18年的专业经验，主要关注复杂系统的设计、企业架构、应用分析与优化等技术，并致力于将这些技术运用到工业制造、自动化、工程学及相关领域中。他是一位有影响力的技术专家和战略专家，也是一位颇受好评的意见领袖，他在IBM所引领和推动的跨学科创新活动受到了很多人的欢迎。爱飞翔,资深软件开发工程师，擅长Web开发、移动开发和游戏开发，有10余年开发经验，曾主导和参与了多个手机游戏和手机软件项目的开发，经验十分丰富。业余爱好文学和历史，有一定的文学造诣。翻译并出版了《Android游戏开发实践指南》《测试驱动的iOS开发》《HTML5Canvas核心技术：图形、动画与游戏开发》《NoSQL精粹》和《JavaScript应用开发实践指南》等书。
目录
目录
题献
译者序
序
前言
致谢
第1章 案例研究1
1.1 业务问题1
1.1.1 技术挑战2
1.1.2 用例2
1.1.3 在机器运转过程中进行实时处理与监控3
1.1.4 为新机器提供无缝的激活服务3
1.1.5 生成工作定单3
1.1.6 尽量减少在为全球客户提供服务时所产生的延迟4
1.2 小结4
第2章 软件架构是什么？为什么需要做软件架构6
2.1 背景知识6
2.2 软件架构是什么7
2.3 为什么需要做软件架构9
2.3.1 把架构视为交流工具9
2.3.2 对项目规划施加影响力10
2.3.3 关注非功能方面的能力11
2.3.4 与设计团队和实现团队做出约定12
2.3.5 为影响力分析提供支持12
2.4 架构视图与架构视点13
2.5 小结16
2.6 参考资料16
第3章 恰到好处地把握架构中的重要方面17
3.1 软件架构中需要关注的一些方面17
3.2 小结19
第4章 系统环境20
4.1 业务环境与系统环境之间的辨析20
4.2 捕获系统环境22
4.2.1 系统环境图23
4.2.2 信息流25
4.3 案例研究：Elixir的系统环境27
4.3.1 Elixir的系统环境图27
4.3.2 Elixir的信息流32
4.4 小结33
4.5 参考资料33
第5章 架构概述34
5.1 什么是架构概述34
5.2 为什么要做架构概述36
5.3 企业视图37
5.3.1 用户与传输渠道39
5.3.2 核心业务流程39
5.3.3 数据与信息40
5.3.4 技术推动力41
5.4 分层视图42
5.4.1 第1层：操作层45
5.4.2 第2层：服务组件层45
5.4.3 第3层：服务层45
5.4.4 第4层：业务流程层46
5.4.5 第5层：消费者层46
5.4.6 第6层：集成层46
5.4.7 第7层：QoS层46
5.4.8 第8层：信息架构层47
5.4.9 第9层：治理层47
5.4.10 进一步研究分层视图的用法47
5.5 IT系统视图48
5.6 案例研究：Elixir的架构概述53
5.6.1 Elixir的企业视图53
5.6.2 Elixir的业务流程54
5.6.3 Elixir的数据及信息54
5.6.4 Elixir的技术推动力55
5.6.5 Elixir的分层视图56
5.6.6 Elixir的IT系统视图57
5.7 小结58
5.8 参考资料59
第6章 架构决策60
6.1 为什么需要做架构决策60
6.2 怎样开始进行架构决策61
6.3 创建架构决策62
6.4 案例研究：Elixir的架构决策67
6.5 小结69
第7章 功能模型71
7.1 为什么需要功能模型71
7.2 可追溯性73
7.3 制定功能模型74
7.3.1 逻辑层面的设计75
7.3.2 规格层面的设计79
7.3.3 物理层面的设计89
7.4 案例研究：Elixir的功能模型91
7.4.1 逻辑层面92
7.4.2 规格层面94
7.4.3 物理层面97
7.5 小结98
7.6 参考资料99
第8章 操作模型100
8.1 为什么需要操作模型101
8.2 可追溯性与服务级别协议102
8.3 制定操作模型104
8.3.1 概念操作模型105
8.3.2 规格操作模型116
8.3.3 物理操作模型122
8.4 案例研究：Elixir的操作模型132
8.4.1 COM132
8.4.2 SOM137
8.4.3 POM138
8.5 小结140
8.6 参考资料141
第9章 集成：方式与模式142
9.1 为什么需要进行集成142
9.2 集成方式143
9.2.1 用户界面的集成144
9.2.2 数据层面的集成144
9.2.3 消息层面的集成147
9.2.4 API层面的集成149
9.2.5 服务层面的集成150
9.3 集成模式152
9.3.1 同步的请求栂煊δＪ?152
9.3.2 批次模式153
9.3.3 同步的批次请求栍Υ鹉Ｊ?153
9.3.4 异步的批次请求栍Υ鹉Ｊ?153
9.3.5 存储并转发模式154
9.3.6 发布柖┰哪Ｊ?154
9.3.7 聚合模式154
9.3.8 管道与过滤器模式155
9.3.9 消息路由器模式155
9.3.10 消息转换器模式156
9.4 案例研究：Elixir的集成视图156
9.4.1 标签1～5所表示的数据流157
9.4.2 标签6～8所表示的数据流158
9.4.3 标签9～10所表示的数据流158
9.4.4 标签11～12所表示的数据流158
9.5 小结159
9.6 参考资料160
第10章 基础设施问题161
10.1 为什么要把基础设施做好162
10.2 需要考虑的基础设施问题162
10.2.1 网络163
10.2.2 托管165
10.2.3 高可用性与容错性169
10.2.4 灾难恢复178
10.2.5 能力规划178
10.3 案例研究：Elixir系统的基础设施问题181
10.4 小结183
10.5 我们现在讲到什么地方了184
10.6 参考资料186
第11章 分析架构入门187
11.1 为什么要做分析188
11.2 进行数据分析所采用的维度189
11.2.1 操作分析189
11.2.2 描述性的分析190
11.2.3 预测性的分析190
11.2.4 指示性的分析191
11.2.5 认知计算192
11.3 分析架构的基础194
11.3.1 分层视图中的各层及五大支柱195
11.3.2 水平层196
11.3.3 垂直层199
11.3.
序言
序软件架构这个词，有些人听了觉得开心，有些人听了要皱眉头，而更多的人对它漠不关心，尤其是那些整天忙着敲代码，没时间思考设计问题的人。
我们知道，软件密集型的系统都是有架构的。有一些架构是刻意而为的，有一些架构是偶然浮现出来的，还有很多架构隐藏在成千上万个小的设计决策中，而这些设计决策，正源于我们敲出来的那些代码。
Tilak先生在本书中精彩地讲解了一些切实可行而且非常实用的方式与方法，以帮助我们架构出复杂的系统。作者是一位拥有实际经验的架构师，他通过一系列案例研究，解释了“架构是什么”以及“架构不是什么”这两个问题，同时还讲解了在软件密集型的系统中，如何使架构成为开发、交付及部署过程的一部分。如果大家了解我，那一定知道我对软件架构这个主题有一些强烈的个人观点，然而在我读过的关于这个主题的那么多本书和那么多篇文章中，我确实觉得Tilak所说的这套方法是建立在坚实的基础之上的，而且他的方法特别容易理解，也特别容易施行。
软件架构并不是一项纯粹的技术，其中还要考虑人的因素。本书正是抓住了这个重要的因素—Tilak把自己在架构工作中汲取的经验教训合理地穿插在本书中，我很欣赏这一点。
架构是个重要的过程，这个过程不仅不能妨碍系统的构建，而且还必须在恰当的时机以合适的资源和特别实用的方式构建出正确的系统。
Grady BoochIBM院士及软件工程首席科学家
| ISBN | 7111550269,9787111550266 |
|---|---|
| 出版社 | 机械工业出版社 |
| 作者 | 蒂拉克·米特拉 |
| 尺寸 | 16 |