内容简介

架构是如何运作并影响人们的日常生活的，在软件行业中架构是如何运作的？架构又是如何指导代码编写的，如何把架构应用在软件工程实践上？带着这些疑问，本书通过大量的实例一步一步揭示出架构背后的原理，以及架构在软件行业的发展，并通过企业实例来展示软件架构的实际应用。本书没有高深的词汇，不仅适合IT从业人员阅读，也适合其他行业的人士阅读。尤其对于想从事架构工作的人而言，是一本不可多得的参考材料。

作者简介

“聊聊架构”是知名IT技术垂直社区网站新推出的一个栏目，内容为软件与网站架构，由一线架构师执笔。本书作者王概凯，网名Kevin，是一位资深的软件架构师，也是这个栏目开山之作的作者，赢得数百万访问量。

目录

第一部分 认识架构

第 1 章 生命周期

1.1 生命周期的识别

1.2 核心与非核心生命周期

1.3 生命周期与分工

第 2 章 时间

第 3 章 为什么会产生架构

3.1 分工

3.2 分工和生命周期

第 4 章 什么是架构

4.1 架构产生的条件

4.2 什么是架构

4.3 架构的生命周期

第 5 章 架构和树

5.1 树与增长

5.2 架构和树

第 6 章 概念

6.1 何为名相

6.2 究竟什么才是相

6.3 概念是沟通的基础

6.4 把握概念的力量

聊聊架构

第 7 章 什么是抽象

7.1 个性与共性

7.2 个性是基础

第 8 章 识别问题

8.1 面对问题有哪些困难

8.2 如何识别问题

8.3 寻找问题主体

第 9 章 切分的原则

9.1 切分就是利益的调整

9.2 为什么需要切分

9.3 切分的原则

9.4 树和分层

9.5 切分与建模

9.6 切分的输出和组织架构

第 10 章 架构与流程

10.1 什么是流程

10.2 流程和架构拆分的关系

第 11 章 什么是架构师

11.1 架构师做什么

11.2 架构师也是人

11.3 人人都是架构师

11.4 架构师和权利

第二部分 软件架构

第 12 章 什么是软件

12.1 以模拟人为目标的冯诺依曼结构和图灵机

12.2 成本为王

12.3 天空才是极限

12.4 软件的作用

目录

IX

第 13 章 软件的生命周期

13.1 软件的开发生命周期

13.2 软件开发的增长

13.3 软件开发的迭代

13.4 软件的运行生命周期

第 14 章 什么是软件架构

14.1 要解决什么问题

14.2 分别是谁的问题呢

14.3 分别有什么问题

14.4 分析问题

14.5 会生成哪些架构

14.6 什么是软件架构

第 15 章 什么是软件架构师

15.1 软件架构师的区别

15.2 软件架构师的困境

15.3 生命周期的思考

15.4 软件架构师的权力

15.5 软件架构师和技术人员对技术的态度区别

15.6 架构师是技术的使用者

15.7 如何保障架构落地

第 16 章 业务、架构和技术三者的关系

16.1 什么是技术

16.2 业务和架构及技术之间的关系

16.3 技术人员和业务人员的关系

16.4 重新发明轮子

16.5 开源技术

第 17 章 软件研发

17.1 软件工程师的兴起和使命

17.2 分工的困境

17.3 软件的迭代

17.4 软件开发的分工

聊聊架构

X

17.5 软件开发模式和架构

17.6 软件工程师的支持者

第 18 章 软件的架构拆分

18.1 软件拆分的原动力

18.2 软件开发团队的拆分

18.3 软件的拆分

18.4 软件开发的基础技术

18.5 软件拆分的第二动力

18.6 架构一步到位

第 19 章 如何写好代码

19.1 什么叫业务逻辑

19.2 业务逻辑分散的危害

19.3 业务逻辑内聚的好处

19.4 代码架构实例

19.5 代码误解

19.6 软件的拆分

第 20 章 单元测试

20.1 什么是单元测试

20.2 单元测试的困境

20.3 单元测试测什么

20.4 如何改造代码

20.5 为什么要做单元测试

20.6 如何做单元测试

第 21 章 软件架构和面向对象

21.1 什么是面向过程

21.2 什么是面向对象

21.3 生命周期和面向对象及面向过程

21.4 架构和面向对象及面向过程

21.5 面向对象的误区

21.6 对象和生命

目录

XI

第 22 章 软件架构与设计模式

22.1 模式以及模式的意义

22.2 什么是设计模式

22.3 软件设计模式

22.4 设计模式和架构

22.5 设计模式的误区

第 23 章 软件架构和软件框架

23.1 访问类框架

23.2 业务类框架

23.3 什么是框架

23.4 框架的特点

第 24 章 软件运维

24.1 软件运行生命周期

24.2 什么是软件运维

24.3 运维的业务模型

24.4 控制变化

24.5 监控变更

24.6 预警变更

24.7 主导变更

24.8 提升变更质量

24.9 运维的架构拆分

第 25 章 软件访问生命周期

25.1 软件访问的业务模型

25.2 软件访问路径的架构拆分

25.3 大规模软件访问的架构拆分

25.4 集群

25.5 数据中心

第 26 章 软件架构和大数据

26.1 什么是大数据

26.2 如何做好大数据

26.3 软件大数据

聊聊架构

XII

第 27 章 软件架构和建筑架构

27.1 软件架构和建筑架构的目标之异同

27.2 软件和建筑的架构扩展之异同

第三部分 软件架构的应用

第 28 章 交易

28.1 什么是交易

28.2 货币的出现

28.3 企业的实质

28.4 软件对交易的影响

28.5 软件的交易

28.6 企业的核心

第 29 章 产品

29.1 什么是产品

29.2 什么是商品

29.3 识别产品

29.4 产品系统

29.5 产品列表

29.6 产品详情

29.7 商品的规则

第 30 章 用户

30.1 什么是用户

30.2 为什么需要用户

30.3 客户的出现

30.4 用户的生命周期

30.5 用户的识别

第 31 章 订单

31.1 什么是订单

31.2 订单的生命周期架构拆分

31.3 订单支付

31.4 订单生命周期

第 32 章 交易系统

32.1 企业的架构拆分

32.2 软件系统的建模

32.3 访问业务模型

32.4 交易软件系统的架构拆分

32.5 服务的产生和粒度

32.6 用户系统的拆分

第 33 章 事务

33.1 什么是事务

33.2 软件中的事务

33.3 数据库事务的滥用

33.4 数据库的正确使用方式

33.5 服务调用

前言/序言

序

在软件行业，架构师和软件工程师是非常辛苦的职业。一方面新技术层出不穷，另一方面业务需求也层出不穷，让人疲于应付。导致的后果就是常常加班，生活质量低下。只有曾经身在其中的人，才能够体会其中的酸甜苦辣。

在软件行业经历过这么多年，也看到了软件行业普遍存在的一些问题，总觉得自己应该为这个行业贡献一点点力量。不期望能够改变这个行业，能够引起一点点思考也是好的，如果能够帮助提升一些软件从业者的工作和生活质量，就超出期望值了。

把自己的想法写出来的过程是痛苦的，从来没有写文字的习惯，也没打算过写书，因此愈发艰难。年初时基于以上同样的想法，在 InfoQ 投稿写了《架构漫谈》专栏，和大家分享一下自己对软件架构的思考，以为算是交差了。不料 InfoQ 的郭蕾多次和我约稿，希望我能够把架构漫谈扩展成一本书。拒绝了很多次，但是脸皮实在是薄，禁不住郭蕾三番五次的游说，狠狠心答应了下来。

把文字写下来传播出去，是要承担很大的责任的，一旦说得不对，伤害的是一大片人。不愿写东西的原因大部分在此。但是想想人非圣贤，总有犯错的时候，把自己的错误暴露出来给大家，也是帮助大家学习。话虽如此，还是郑重声明，本书的内容都是个人的思考和个人的观点，并非学术的结论，请各位读者不要当作结论全盘接受。反而读者应该质疑书中的各种观点，尽量自行思考，如此才会有所收获。本书的目的也仅仅是为了引发大家的思考。

思及自身水平有限，文字功底也差，难免伤人慧命，深感惭愧和惶恐！望各位读者，鉴其愚诚，不吝慈悲指正！

——王概凯 Kevin

前言

现代的软件从业者，都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育，基本上都是从科学研究领域脱胎出来的，教育的目的也理所当然的主要是为科学研究领域服务。而随着社会的发展，软件不断地渗透到不同的业务领域，涉及到普通人生活的方方面面。以科学研究为目的的软件教育，和日益深入人们生活的软件应用，产生了很大的隔阂。以致于很多计算机和软件专业毕业的学生，进入企业工作后，总是感叹学校所学习的知识派不上用场，必须得重新学起，才能够达到企业的要求。

而这些重新学习的内容，又往往是以技术为主的。技术的更新换代太快，往往也导致想跟上新技术的我们力不从心。技术和业务的关系是如何的？业务又是怎么运作的？很少有人去问这些问题。即使有人问了，也很难有人可以提供建议。

软件技术学习到一定的地步，又会发现软件架构是一个门槛。一直以来，在软件行业，对于什么是架构有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论应用架构、硬件架构、数据架构等。而事实上，架构在软件发明时的很多年以前就已经存在了。众说纷纭，莫衷一是，这也给大家带来了很多困扰。

业务和架构，是压在软件从业人员身上的两座大山。而软件从业人员手上却只有一个武器：技术。可是这个武器还时灵时不灵，就好像金庸小说《天龙八部》中段誉的六脉神剑，并不总是能够解决问题，有时还会带来麻烦。

软件并不是虚无缥缈的东西，它和现实生活是紧密相关的。业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题，心里面厌恶，但却又无法逃避。因为这个排斥的心理，工作中始终想避开和人有关系的地方。因此在技术之前，还需要做一些准备工作，用来连接现实生活，联系上人，让大家知道处理人的问题并不可怕。建立了这个相关性，每个人就都可以自行思考了。

不仅人类受限于自身的生命周期，凡事都有其生命周期。理解了生命周期，就可以看到很多隐藏在背后的规律，以及这些规律之间的联系。因此，本书试图从生命周期入手，描绘出一张整体的画卷，帮助包括技术人员在内的大家定位自己处于什么地方，自己在起什么作用，别人又在什么地方，他们又在起什么作用。

明白了自己的位置和别人的位置，自然也就清楚自己有什么，缺什么，要往哪个地方走，从哪些地方入手了。所谓“知己知彼，百战百胜”，知道这些后中，面对人打交道时也就有了自己的思考方式，能够进行独立思考，对业务也不再厌恶以致于逃避，而是为能帮助业务人员分析及解决问题而自豪。

本书虽然不是技术书籍，不谈技术，但却是以帮助技术人员为出发点。本书的内容可以作为连接技术人员和现实世界的桥梁，用来使技术人员不再悬在空中使不出力。对于非技术人员而言，本书可以帮助其理解软件开发的特殊性，拉近与技术人员的距离，能够更有针对性地与技术人员合作。

当然，读完本书不会使读者突然学会神功，打通任督二脉。因为每个人的成长，最终还是要靠自己的思考和实践。本书的思考也不能够代替读者自己的思考，在解决某个业务问题时也无法从书中直接找到答案。本书可以提供给大家的是一个思考的出发点，一个思考的方向，一个思考的角度，使得大家不再惧怕或排斥业务，并可以像业务人员一样思考，和架构师一样思考，不再受困于业务和架构，甚至是技术本身。如果本书能够帮助大家跨过这个门槛，并从这里开始展开思考，那么目的就达到了。

一次买了很多书，都没来得及看

书不错，便宜了买的

粗粗翻了一下，描述层面毕竟高，不是实战经验介绍，描述流程性的东西太多，有些枯燥。有点借鉴意义

一次买了很多书，都没来得及看

向着架构师进击

聊聊“架构”

聊聊“架构”

1111111111

粗粗翻了一下，描述层面毕竟高，不是实战经验介绍，描述流程性的东西太多，有些枯燥。有点借鉴意义