IBM院士、软件工程首席科学家Grady Booch作序鼎力推荐，IBM杰出工程师、首席技术官Tilak Mitra亲笔撰写，Amazon全五星评价，是该领域的第一本完备指南
通过一整套实用的案例研究，逐步讲解系统环境、架构概述、架构决策、功能模型、操作模型、系统设计的集成模式及基础设施

封底
恰到好处地完成架构工作——本书详尽而务实地指导大家对实际工作中的IT项目进行架构

要想构建有效的架构，软件架构师就必须像动物绘本的画师那样，在清晰与模糊之间游走。这虽然很难，但却必须做到。如果不能在二者之间达成平衡，那么通常就会直接损害系统的设计与实现。由IBM杰出工程师与首席技术官蒂拉克·米特拉先生写的这本书，是该领域的第一本完备指南，用来全程指导软件架构师制定出“恰到好处”的解决方案架构。作者会告诉我们应该怎样确定并捕获最为重要的架构工件，同时又不陷入过度的设计和过多的文档之中。作者所讲解的方法相当务实，使我们总能够制定出成功的软件架构。
本书通过详尽的解说与务实的指导，告诉大家应该怎样给实际工作中的IT项目设计架构。这些内容不受制于具体的系统、开发方法或开发环境。作者着重讲解了应该怎样认定那些需要重点关注的架构工件，以及怎样与利益相关者之间就正在演化的解决方案进行沟通，以填补架构与实现之间的鸿沟。
通过一整套实用的案例研究，全程指引大家迭代式地构建解决方案架构。书中逐步讲解了系统环境、架构概述、架构决策、功能模型、操作模型、系统设计的集成模式及基础设施等方面的重要话题。整本书以清晰明快的笔调准确地告诉大家，怎样才能在规定的时间和资金范围之内，自信地打造出成功的软件架构。
本书涵盖下列内容
用架构来促进相关人员之间的沟通以及项目的规划，并为功能型需求和非功能型需求（诸如可扩展性、性能、可维护性及安全性等）提供支持；
专注于当前的架构问题，而不过分依赖理论和一般规律；
对适用于架构工作的分析技术进行介绍；
“恰到好处”地捕获与系统环境、架构概述、架构决策、功能模型及操作模型有关的信息；
介绍集成模式以及这些模式在架构设计中的用法；
介绍软件架构所涉及的基础设施问题；
通过真实的案例研究来展示软件架构的各个方面。

前
本书由IBM杰出工程师、首席技术官Tilak Mitra亲笔撰写，Amazon全五星评价。全书通过一整套实用的案例研究，逐步讲解了系统环境、架构概述、架构决策、功能模型、操作模型、系统设计的集成模式及基础设施等方面的内容。
本书共分12章。第1章描述了一个虚构的案例，以演示问题的陈述；第2章给出软件架构的一些背景知识，以及一些能够促使我们做好架构工作的成熟价值理念；第3章讲解软件架构中需要关注的一些方面；第4章介绍IT系统的系统环境；第5章介绍3种关键视图：企业视图、分层视图和IT系统视图；第6章讨论架构决策的重要性，并指导大家捕获这些决策；第7章演示怎样确定系统在功能方面的宏观设计工件，并告诉大家如何用文档来记录这些工件；第8章着重讲解系统的操作模型；第9章研究与系统集成有关的基本技术；第10章简要地讲解与主机托管有关的关键因素，帮助读者更有效地利用计算资源和存储资源；第11章简单介绍数据分析的价值及各种形式，并从架构的角度演示数据分析蓝图中一些较为关键的功能构建块；第12章分享了一些有用的实际工作经验。
本书适合软件架构师、项目经理、高层管理人员、高校计算机及相关专业师生阅读。

后
Tilak Mitra　IBM全球企业咨询服务部首席技术官（CTO）。他是IBM杰出工程师，在IT界拥有超过18年的专业经验，主要关注复杂系统的设计、企业架构、应用分析与优化等技术，并致力于将这些技术运用到工业制造、自动化、工程学及相关领域中。他是一位有影响力的技术专家和战略专家，也是一位颇受好评的意见领袖，他在IBM所引领和推动的跨学科创新活动受到了很多人的欢迎。

爱飞翔　资深软件开发工程师，擅长Web开发、移动开发和游戏开发，有10余年开发经验，曾主导和参与了多个手机游戏和手机软件项目的开发，经验十分丰富。业余爱好文学和历史，有一定的文学造诣。翻译并出版了《Android游戏开发实践指南》《测试驱动的iOS开发》《HTML5 Canvas核心技术：图形、动画与游戏开发》《NoSQL精粹》和《JavaScript应用开发实践指南》等书。

软件架构这个学科已经有半个世纪的历史了。此概念于20世纪60年代引入，它的灵感来源于建筑物的架构，其中涉及在开始盖楼之前拟定的一些蓝图，这些蓝图描述了建筑师对建筑物的结构所制定的设计方案与规格说明。建筑物的蓝图给出了建筑物在功能方面的设计方案，也就是楼层的空间布局示意图，以及每个建筑工件（例如门、窗、房间、浴室、楼梯等）的尺寸。在使建筑物得以运作的那些方面，蓝图也提供了详细的设计方案，例如承载建筑结构的地基、电线、水管和输气管道的设计，以及下水道系统等，要想使建筑物的功能全面运转并发挥效用，这些方面都是不可缺少的。
信息技术（information technology，IT）中的软件架构，其真正灵感来源于建筑架构学中的土木工程（civil engineering）这一学科。据此，我们可以把软件架构大致分成功能架构（functional architecture）和操作架构（operational architecture）两大类。软件架构在 20世纪70年代开始得到大规模实践，到了20世纪90年代，它已经成为IT界的主流，此时各种架构模式也相继涌现。这些模式会随着工作中反复出现的一些用法而演化，所谓反复出现（recurrence），是指这些用法会一直重复地出现在日常应用中。我们之所以能从软件架构中提炼出架构模式，是因为有一个先决条件已经得到了满足。这个条件就是软件架构已经得到了充分的实践，从而成为业界的主流做法，并且已经作为一门正式的研究与实践学科，得到了业界的认可。
IT系统的复杂度越来越高，因此各种IT项目都会频繁而且广泛地运用软件架构技术。软件架构的方式也随着运用面的扩大而变得丰富起来，并且还涌现出了很多流派，它们采用不同的观点来看待软件的架构，并根据其在开发软件系统时所取得的实际经验来总结并推广各自的观点。软件架构的流派和观点变得越来越多，这使很多IT工作者都不知道应该采信哪个流派的观点。大家不妨回想一下，看看自己有没有对下面这些问题表示过困惑？
我读过很多架构方面的书籍，也看过很多期刊和杂志，但是我究竟应该怎样把这些互不相同的架构流派汇整起来呢？
这些流派中有哪些方面是我比较喜欢的？
这些方面是否可以互补？
如果我是一名架构师，面对着一个时间和预算都受限制的复杂软件系统，那么应该从哪里开始实现它呢？
我是否能成为一名成功的软件架构师？
笔者也曾陷入这样的困惑中。软件架构师所要面对的一项艰难挑战，就是寻找一种最佳的方式，来确定系统或应用程序的架构，并对其进行设计。对软件架构的要义进行把握，既是一种科学，又是一种艺术。我们要用适当的描述语言来定义系统的软件架构，并对其加以分析和理解，从这个层面来看它是科学。同时，我们还要用清晰、明确并且简洁的方式把这个架构描绘出来，以便与不同的利益相关者就系统的解决方案架构进行有效的沟通，从这个层面来看它又是艺术。软件架构师怎样才能抓住关键的架构工件（architecture artifact），从而清晰地描述出整个解决方案呢？这正是难点所在。过度的设计和过多的文档，会拖慢项目的进度，并给项目的交付带来风险，而对软件架构所做的不恰当处理，则会使开发者无法领悟这套架构，这是个很关键的问题。如果开发者不能很好地理解软件的架构，那么他们就无法恰当地遵循技术方面的规范和限制，也无法恰当地使用这套架构来设计并开发系统中的各个部件。在软件开发的整个生命周期中，这个问题只会越来越严重。
2008年，笔者在IBM developerWorks网站上写了一系列专门谈论软件架构的文章。在连续发布4部分之后，由于某些个人原因，没有再往下写。接下来的几年，笔者看到了一些网友提出的问题，也收到了一些称赞，然而除此之外，还有另一类信息促使我进行更多的思考。比如，下面这两个问题：
“先生您好。我正在参考您的系列文章来撰写硕士论文。请问下一部分的文章什么时候发布？”
“Mitra先生，我们采用您所说的框架做了IT项目，但是项目暂停了，因为您的下一篇文章还没出来。求助。”
某一天早晨，我忽然感觉读者确实需要一本架构方面的书籍，它必须写得简单、明确、易于理解、便于描述，而且最为重要的是，它必须足够实用，能够执行。这本实用的书籍要能够给IT工作者和软件工程专业的学生带来较大的帮助，使他们明白怎样对软件系统进行架构。过了一段时间之后，我终于决定开始写书了。本书代表着软件架构领域中的集体智慧、经验、学问和知识，这些内容是笔者根据自己从业18年来的经历收集而成的。本书面对的读者有很多，其中包括：
软件架构师。书中会给出一些实用而且可以反复运用的指导原则，以帮助软件架构师来研发软件的架构。
项目经理。本书将会帮助读者理解并领会系统架构中的关键元素，它们是良好的架构所必备的元素，本书还会解释怎样才能在进行项目规划时把架构活动控制得恰到好处。
高校学生。本书将会帮助大家理解怎样把软件架构中的理论转述成实际的问题，并对其加以实现。无论技术如何发展，本书都可以当作长期的参考资料。
教师。通过本书，教师可以帮助学生把软件架构中的各种理论与实际工作联系起来，使学生变成能够应对实际项目的软件架构师。
首席管理者（C-level executive）或高层管理人员。本书将会帮助他们意识到研发良好的系统架构所必备的要素，对于IT界的任何一种创新活动来说，这种意识都会给公司带来间接的好处，使他们可以更好地领悟IT架构在整个公司中的基础地位。
笔者想把这本书写成一本实用的教程，使读者可以按照里面所说的方法，通过多个阶段的演进来迭代式地构建出软件的架构。书中会指出各种架构工件的运用方式，使大家可以把这些清晰、简明、精准而且易懂的工件，恰到好处地运用在实际的应用场景中。在整本书中，笔者会以较为随意的方式来使用“软件”（software）“系统”（system）和“解决方案”（solution）这三个词，由于它们在本书中指的都是架构（architecture），因此这三者之间是可以互换的。笔者之所以要采用这种不拘于字面意思的交替指称方式，是为了使大家明白：在IT界，这三个词之间的界限其实是相当模糊的。
从哲学角度来看，东方哲学和西方哲学之间的区别，在于它们对直觉和理性这两种感知形式的接受程度有所不同，前者更强调直觉，而后者更强调理性。西方世界普遍相信，并且主要依赖于理性的、科学的和演绎式的推理。而东方世界则更加看重凭直觉所获取的知识，他们认为，更高形式的意识（在这里指的是知识）是通过观察（也包括反思自己的内心世界）得来的，而不是仅仅通过实验式的归纳得来的。笔者生长于印度加尔各答一个文化较为多元的孟加拉家庭中，十分认同东方式的信仰和知识观念，我认为自觉的意识最终需要通过自觉的自由意志来获得，知识的奥义也要通过直觉和归纳式的推理来领悟。后来，笔者在西方世界生活了将近20年，在这段时间里，我开始看重科学和理性的知识形式。我认为，一个普通人要想在这个残酷竞争的世界中生存，就必须掌握由理性与科学手段所得到的知识，对于科学、技术和IT领域来说更是如此。等到自己的工作稳定下来之后，可以去深入探索直觉感知力和归纳式推理，这种探索虽然未必会带来回报，但或许会帮助我们从人生的存在中求得解脱。
在这本书中，笔者试着用一种解说的办法，通过归纳式的理性推理来帮助读者掌握实用的软件架构方式。等到掌握了这种理性的知识之后，读者可以把注意力放在归纳式的推理上，以探求更为玄妙的直觉知识。如果把解决最困难的架构问题比喻成寻求圣杯（Holy Grail），那么用直觉来感知软件的架构就相当于层次更高的开悟了，这种境界，我想应该是大家梦寐以求的吧。
等到看完本书并掌握了它的要义之后，希望你能焕然一新，变成一位务实的软件架构师。软件架构是个有趣的学科，其中的理性知识，我想读完这本书之后，大家应该就可以了解到。而凭直觉才能获得的那一部分知识，则需要以理性知识为基础，继续去探索。在这一方面，连笔者也只是刚刚入门而已。
另外再说一句，每章开头的那些格言，其实都是笔者自己编的。

计算机\程序设计

恰到好处地完成架构工作——本书详尽而务实地指导大家对实际工作中的IT项目进行架构

要想构建有效的架构，软件架构师就必须像动物绘本的画师那样，在清晰与模糊之间游走。这虽然很难，但却必须做到。如果不能在二者之间达成平衡，那么通常就会直接损害系统的设计与实现。由IBM杰出工程师与首席技术官蒂拉克•米特拉先生写的这本书，是该领域的第一本完备指南，用来全程指导软件架构师制定出“恰到好处”的解决方案架构。作者会告诉我们应该怎样确定并捕获最为重要的架构工件，同时又不陷入过度的设计和过多的文档之中。作者所讲解的方法相当务实，使我们总能够制定出成功的软件架构。

本书通过详尽的解说与务实的指导，告诉大家应该怎样给实际工作中的IT项目设计架构。这些内容不受制于具体的系统、开发方法或开发环境。作者着重讲解了应该怎样认定那些需要重点关注的架构工件，以及怎样与利益相关者之间就正在演化的解决方案进行沟通，以填补架构与实现之间的鸿沟。

通过一整套实用的案例研究，米特拉先生全程指引大家迭代式地构建解决方案架构。作者逐步讲解系统环境、架构概述、架构决策、功能模型、操作模型、系统设计的集成模式以及基础设施等方面的重要话题。整本书以清晰明快的笔调准确地告诉大家，怎样才能在规定的时间和资金范围之内，自信地打造出成功的软件架构。

本书涵盖下列内容：

·用架构来促进相关人员之间的沟通以及项目的规划，并为功能型需求和非功能型需求（诸如可扩展性、性能、可维护性及安全性等）提供支持

·专注于当前的架构问题，而不过分依赖理论和一般规律

·对适用于架构工作的分析技术进行介绍

·“恰到好处”地捕获与系统环境、架构概述、架构决策、功能模型及操作模型有关的信息

·介绍集成模式以及这些模式在架构设计中的用法

·介绍软件架构所涉及的基础设施问题

·通过真实的案例研究来展示软件架构的各个方面

[印] 蒂拉克·米特拉（Tilak Mitra）著：暂无简介

爱飞翔　译：暂无简介

软件开发工作是由需求引领的，而需求会随着业务的发展逐渐变得庞杂。为了对持续变化的需求进行有效的管理，很多开发者与软件公司都建立了软件架构这样一个概念。尽管软件业与传统的实物产业不同，但它依然可以通过良好的架构指导项目的设计、编码、测试、部署以及维护等诸多阶段。从这个意义上讲，软件架构与其他行业的架构之间有相通的地方。
然而，这并不是一本泛论架构的图书，它谈论的是软件架构，并且尤为关注软件架构中的实际做法。与题材类似的其他书籍相比，本书在核心理念、结构安排以及术语使用等方面都有自己的特色。
本书的核心理念体现在恰到好处（just enough）这个词上。架构固然应该对实现起指导作用，但这个指导作用应该留有一定的余地，使我们可以对架构进行反思，并根据项目的发展情况对其做出调整。软件架构要想做得务实，就需要把握住恰到好处的原则，架构师要知道应该把模块细化到何种程度，才能使开发团队在既定的大方向下灵活地进行发挥。
在结构的安排上，作者首先简介了贯穿全书的Elixir项目，后续各章分别用该项目来做案例研究，以演示软件架构的某一个方面，把这些方面拼合起来就可以形成一套完整的案例。把该案例与工作中的实际项目进行对比，或许会对大家有所启发。接下来，作者谈了软件架构的含义和意义，并指出了描述架构所用的几种视点。然后，作者明确提出架构中需要关注的7个方面，并且用7章的篇幅来详细地进行讲解，使我们明白怎样才能恰到好处地应对这些方面。本书最后给出3个专题，分别介绍了大数据时代的分析架构、作者在多年工作中所积累的经验，以及业界经常谈论的25个架构话题。
在术语的使用上，作者经常采用两种或三种称呼来指代同一个概念，这不仅反映了该概念所具有的多重意义，而且还使读者感受到一种现象：不同的人在不同的情境下称呼同一个概念时，关注的重点是有所区别的。由于作者就职于IBM公司，因此译者在翻译术语时，优先考虑采用IBM网站上已有的译法，对于同时具有多种译法的术语，则酌情采用其中较常见的一种或两种。
纵观全书，作者清晰地描绘了软件架构工作的执行脉络，并指出了从系统环境到软件部署等诸多环节中所应注意的各种问题。需要提醒大家的是，软件架构必须通过适当的代码及硬件配置得以体现，因此，架构应该尽量与实际的编码及测试工作相契合，而且要与后两者保持互动。
在翻译过程中，我得到了机械工业出版社华章分社诸位编辑和工作人员的帮助，在此深表谢意。
由于译者水平有限，错误与疏漏之处，请大家发邮件至eastarstormlee@gmail.com，或访问github.com/jeffreybaoshenlee/psa-errata/issues留言，予以批评指正。

爱飞翔

题献
译者序
序
前言
致谢
第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　COM …… 132
8.4.2　SOM …… 137
8.4.3　POM …… 138
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.4　五大支柱 …… 201
11.4　架构构建块 …… 205
11.4.1　数据类型层中的ABB …… 206
11.4.2　数据获取与访问层中的ABB …… 207
11.4.3　数据存储库层中的ABB …… 208
11.4.4　模型层中的ABB …… 209
11.4.5　数据集成与整合层中的ABB …… 210
11.4.6　分析解决方案层中的ABB …… 211
11.4.7　消费者层中的ABB …… 213
11.4.8　元数据层中的ABB …… 213
11.4.9　数据与信息安全层中的ABB …… 214
11.4.10　描述性的分析中的ABB …… 215
11.4.11　预测性的分析中的ABB …… 215
11.4.12　指示性的分析中的ABB …… 217
11.4.13　操作分析中的ABB …… 217
11.4.14　认知计算中的ABB …… 218
11.5　小结 …… 219
11.6　参考资料 …… 220
第12章　架构经验谈 …… 222
12.1　各种敏捷开发观点应该加以融合 …… 222
12.2　传统的需求收集技术过时了 …… 224
12.3　MVP范式值得考虑 …… 225
12.4　不要忙于应付各种事务 …… 226
12.5　预测性的分析并不是唯一的分析切入点 …… 227
12.6　领导能力也可以通过培养而获得 …… 227
12.7　架构不应该由技术来驱动 …… 228
12.8　开源软件很好，但要谨慎使用 …… 230
12.9　把看似简单的问题总结起来 …… 230
12.10　根据技术产品的核心优势来确定架构基线 …… 231
12.11　小结 …… 232
12.12　参考资料 …… 232
附录A　25个实用小知识 …… 233
附录B　Elixir的功能模型（续） …… 252