《聊聊架构》读后感.md

我做架构时有困惑，和有架构师头衔的人聊天时，也并没有发现他们在架构上在讲人话。
什么B/S、C/S，三层架构，MVC等等，知道它们的样子，也明白它们的好处，但没能再向上抽象出原理。
在InfoQ上读到王概凯的 架构漫谈 时，惊为天人，就好像突然有个同类用能懂的语言和我在沟通了。
这本书我借了好几个月了，马上要还给公司。古语说书非借不能读也，我看是借了书快还的前几天才会读。。
我想趁此机会把我的一些感受写下来。

书的简介

我们总是喜欢借鉴别人的架构实践，参考别人的架构图，但体会过的人都知道，由于各家公司的行业背景、发展情况、人力资源都不同，所以真正意义上的架构借鉴难度很大。 《聊聊架构》希望揭开事物的外在“表皮”，再现架构深层之理，向读者揭示最本质的架构之道。 架构是如何运作并影响人们的日常生活的，在软件行业中架构是如何运作的？架构又是如何指导代码编写的，如何把架构应用在软件工程实践上？带着这些疑问，《聊聊架构》通过大量的实例一步一步揭示出架构背后的原理，以及架构在软件行业的发展，并通过企业实例来展示软件架构的实际应用。《聊聊架构》没有高深的词汇，不仅适合IT 从业人员阅读，也适合其他行业的人士阅读。尤其对于想从事架构工作的人而言，是一本不可多得的参考材料。

书的目录

目录 · · · · · ·

第一部分 认识架构 1
第一章 生命周期 2
1). 生命周期的识别 3
2). 核心与非核心生命周期 3
3). 生命周期与分工 5
第二章 时间 9
第三章 为什么会产生架构 11
1). 分工 11
2). 架构和生命周期 12
第四章 什么是架构 13
1). 架构产生的条件 13
2). 什么是架构 14
3). 架构的生命周期 16
第五章 架构和树 18
1). 树与增长 18
2). 架构和树 19
第六章 概念 20
1). 何为名相？ 20
2). 究竟什么才是相？ 21
3). 概念是沟通的基础 21
4). 把握概念的力量 22
第七章 什么是抽象 23
1). 个性与共性 23
2). 个性是基础 24
第八章 识别问题 25
1). 面对问题有哪些困难 25
2). 如何识别问题 26
3). 寻找问题主体 28
第九章 切分的原则 29
1). 切分就是利益的调整 29
2). 为什么需要切分？ 30
3). 切分的原则 30
4). 树和分层 31
5). 切分与建模 32
6). 切分的输出和组织架构 32
第十章 架构与流程 34
1). 什么是流程 34
2). 流程和架构分拆的关系 35
第十一章 什么是架构师 36
1). 架构师做什么 36
2). 架构师也是人 36
3). 人人都是架构师 37
4). 架构师和权利 38

第二部分 软件架构 39
第一章 什么是软件 40
1). 冯诺依曼结构，图灵机，以模拟人为目标 40
2). 成本为王 40
3). 天空才是极限 41
4). 软件的作用 42
第二章 软件的生命周期 45
1). 软件的开发生命周期 46
2). 软件开发的增长 46
3). 软件开发的迭代 48
4). 软件的运行生命周期 48
第三章 什么是软件架构 50
1). 要解决什么问题？ 50
2). 分别是谁的问题呢？ 51
3). 分别有什么问题？ 51
4). 分析问题 52
5). 会生成哪些架构 53
6). 什么是软件架构 55
第四章 什么是软件架构师 57
1). 软件架构师的不同 57
2). 软件架构师的困境 58
3). 生命周期的思考 58
4). 软件架构师的权利 59
5). 软件架构师和技术人员对技术的态度区别 60
6). 架构师是技术的使用者 61
7). 如何保障架构落地 62
第五章 业务、架构和技术三者的关系 64
1). 什么是技术 64
2). 业务、架构和技术之间的关系 66
3). 技术人员和业务人员的关系 68
4). 重新发明轮子 69
5). 开源技术 69
第六章 软件研发 72
1). 软件工程师的兴起和使命 72
2). 分工的困境 74
3). 软件的迭代 76
4). 软件开发的分工 77
5). 软件开发模式和架构 78
6). 软件工程师的支持者 80
第七章 软件的架构拆分 82
1). 软件拆分的原动力 82
2). 软件开发团队的拆分 85
3). 软件的拆分 86
4). 软件开发的基础技术 88
5). 软件拆分的第二动力 90
6). 架构一步到位？ 90
第八章 如何写好代码 92
1). 什么叫业务逻辑？ 98
2). 业务逻辑分散的危害 98
3). 业务逻辑内聚的好处 100
4). 代码架构实例 101
5). 代码误解 103
6). 软件的拆分 104
第九章 单元测试 106
1). 什么是单元测试 106
2). 单元测试的困境 106
3). 单元测试测什么 107
4). 如何改造代码 108
5). 为什么要做单元测试 111
6). 如何做单元测试 113
第十章 软件架构和面向对象 115
1). 什么是面向过程 115
2). 什么是面向对象 116
3). 生命周期和面向对象、面向过程 117
4). 架构和面向对象、面向过程 117
5). 面向对象的误区 118
6). 对象和生命 119
第十一章 软件架构与设计模式 121
1). 模式以及模式的意义 121
2). 什么是设计模式 122
3). 软件设计模式 123
4). 设计模式和架构 124
5). 设计模式的误区 126
第十二章 软件架构和软件框架 130
1). 访问类框架 130
2). 业务类框架 132
3). 什么是框架 132
4). 框架的特点 132
第十三章 软件运维 134
1). 软件运行生命周期 134
2). 什么是软件运维？ 135
3). 运维的业务模型 136
4). 控制变化 138
5). 监控变更 141
6). 预警变更 142
7). 主导变更 144
8). 提升变更质量 146
9). 运维的架构拆分 148
第十四章 软件访问生命周期 151
1). 软件访问的业务模型 151
2). 软件访问路径的架构拆分 153
3). 大规模软件访问的架构拆分 155
4). 集群 156
5). 数据中心 158
第十五章 软件架构和大数据 161
1). 什么是大数据 161
2). 如何做好大数据 162
3). 软件大数据 163
第十六章 软件架构和建筑架构 165
1). 软件架构和建筑架构的目标之异同 165
2). 软件和建筑的架构扩展之异同 169

第三部分 软件架构的应用 172
第一章 交易 173
1). 什么是交易 173
2). 货币的出现 174
3). 企业的实质 175
4). 软件对交易的影响 176
5). 软件的交易 176
6). 企业的核心 177
第二章 产品 179
1). 什么是产品 179
2). 什么是商品 182
3). 识别产品 184
4). 产品系统 185
5). 产品列表 185
6). 产品详情 186
7). 商品的规则 186
第三章 用户 188
1). 什么是用户 188
2). 为什么需要用户 189
3). 客户的出现 189
4). 用户的生命周期 190
5). 用户的识别 191
第四章 订单 192
1). 什么是订单 192
2). 订单的生命周期架构拆分 193
3). 订单支付 195
4). 订单生命周期 196
第五章 交易系统 197
1). 企业的架构分拆 197
2). 软件系统的建模 201
3). 访问业务模型 205
4). 交易软件系统的架构分拆 208
5). 服务的产生和粒度 209
6). 用户系统的分拆 210
第六章 事务 214
1). 什么是事务 215
2). 软件中的事务 216
3). 数据库事务的滥用 217
4). 数据库的正确使用方式 217
5). 服务调用 218

重点

什么是架构？为什么要有架构？

架构是指把不断寻求产品的本质，简化不能再简化，剩下的部分就是架构。  
架构是为了成长，成长必须依赖团队，团队需要合理分工。得到产品的架构后，由于结构更简单，我们更能把握产品的开发。抽离出去的部分获得了独立发展的机会，分工合理，成长空间更大。

向现实世界学习架构

架构并非软件行业的概念，它是一种通用的概念。现实世界是有架构的，一个国家和公司的组织架构都是经过精心设计和调整的。  
软件行业作为现实世界的模拟，需要从现实世界的架构和流程中获取架构。  
架构的规律是发现生命周期。

架构中使用的基本概念：生命周期、树、概念

生命周期

生命周期的概念至关重要，在别的地方也许没有，但这里很重要，只要能自圆其说就可以接受
生命周期的识别：谁的生命周期。生命周期是随着时间的推移从生成到消亡的过程。
核心生命周期。事物动态变化，生命周期可能被拆分，核心的生命周期是不变的。
生命周期被拆分后。
	核心的生命周期本质是没变的。但被拆出去的部分变的更抽象。
	子生命周期变成了一个新的生命周期，生命周期的主体也发生了变化。它被核心生命周期唤起，它的结果返回给核心生命周期。
		但是子生命周期实际上是新的生命周期。它是可以独立存在的。
生命周期的拆分并不改变执行顺序，执行顺序上还和原有的保持一致。但是执行的位置发生了变化，并不是都在原有的生命周期中执行。

树

树的形状非常适合架构。树的主干就是架构的生命周期。树的分支就是子生命周期。
要强调主干的作用，不能长歪；也不能忽视分支，分支成长不好，会影响主干。
主干的增长和枝叶的增长是相互促进的，要保证这个关系。 层与树是什么关系？
 先有树，后有层。比如公司作为一棵树先存在，再有管理层，员工层。

概念

概念是沟通的基础，是大家的共识。
如果想学习一项新的技术，先去探索这些概念产生时所要解决的问题（难于寻找高质量的资料，比如微积分），学习这些新的技术或者概念就会事半功倍。

识别问题

对于架构来说，识别问题就是把核心的生命周期找到。
识别问题的方法，问题的主体是谁，主谓宾语法分析。
架构师的能力大部分体现在“是谁的问题”的识别上。

分工

切分与利益

架构师的权力

软件拆分的原动力

如何写好代码？

银行：柜台、业务、文件柜
软件：服务、业务、存储
服务是对客户的，是人话。业务是内部的，是专业的。业务可以专注自己的发展。
服务不记录业务数据。它将数据从存储中加载交给业务去处理。它将业务处理后的数据交给存储去保存。
业务逻辑有行为无记忆。
存储有记忆无逻辑。
服务代码使用glue code将业务和存储联系起来。
存储挂在业务上叫ActiveRecord。

服务和glue code都是访问逻辑。访问逻辑是顺序调用的，不会有if else的判断。

内聚就是要确保一个事物的生命周期是完整的。所谓完整，就是指一个生命周期的主体，从生到死之间的整个过程中，所发生的行为和状态是累积在一个主体上的。

业务代码要单元测试。服务代码因为需要和用户相关的上下文，它也没有逻辑，所以不需测试，最多做个连通性测试。

服务代码不要考虑代码复用。它本来就是为特定的角色服务的，复用反而会产生不必要的耦合。
服务太多不是问题，服务的生命周期管理才是问题。Service Governance来解决服务注册和查找。

OrderService(OrderManager[glue code] use AccountManager) use AccessService
OrderManager use Order(Business)
OrderManager use OrderEntity(Repository)

软件的核心是业务的模拟。根据业务的生命周期来拆分。

单元测试

服务代码和存储代码是不需要单元测试的，因为都是简单的顺序执行。
就像单元测试本身是不需要单元测试的，因为单元测试的代码都是简单的顺序执行，并没有逻辑。
单元测试：自己的代码才需要测试，外部的代码不需要。把访问代码和逻辑代码分开，访问代码提供上下文，逻辑代码通过参数获得上下文，这样逻辑代码就可测试了。

:前端的单元测试为什么难做？因为前端的结果是展示在页面上的，所以它不是很容易验证。

框架的特点

服务

服务于柜台。

事务

事务是通用概念。不应该受限于关系数据库的事务，应该根据实际业务来确定如何实现事务，在应用层或使用DB的事务。