作者：王概凯（Kevin Wang）
出版：电子工业出版社
全书核心命题
架构不是软件行业的专有词，而是人类社会的普遍现象
架构的本质：通过对生命周期的拆分，达到增长
架构产生的根因：人对时间的恐惧——每个人的时间有限，必须通过分工并行来延长有效生命
软件的本质：用虚拟人替代现实中的人，以降低业务成本、提升生产力
第一部分：认识架构（第1-11章）
第1章 生命周期
所有事物都有生命周期：从出生到消亡（生住异灭）
生命周期核心特征：按时间顺序推进，不可逆
核心生命周期 vs 非核心生命周期：
核心：主体不变，必须自己执行（如人必须自己吃饭）
非核心：主体改变，可以分工出去（如种粮、烧饭可委托他人）
内聚的本质：一个生命周期主体的所有行为和状态，都累积在该主体上
拆分规律：生命周期拆分后，非核心部分可在空间上并行，但核心部分仍然时间串行
关键洞见
非核心生命周期拆分出来后，变成通用服务，反而获得更大生命力
大生命周期变精简，可以更专注于自身核心活动
第2章 时间
时间是事物变化的度量，生命周期的变化体现时间
人对时间的恐惧是推动人类进步的根本动力
在有限生命内创造更多产出 = 相当于延长了生命
尽可能做自己最擅长的事，才能获得最大产出
第3章 为什么会产生架构
产生下一代 → 男女群居 → 性别分工 → 地域分工 → 人类架构诞生
分工的意义：原来串行的生命周期活动，通过分工变成空间并行
分工 = 把非核心生命周期交给擅长的人执行，自己专注核心
人类是唯一能按意愿控制、重新组合其他事物生命周期的生命，这是人类架构产生的必要条件
第4章 什么是架构
架构产生的4个条件（缺一不可）
必须由人执行的工作（不需要人介入就不需要架构）
每个人时间有限（同时只能专注一件事）
对目标系统有更高要求（不满足现状）
目标系统复杂性超过单个人能力极限
架构的4个要点
根据要解决的问题，界定目标系统边界（找核心生命周期主体）
围绕核心生命周期进行切分，让非核心生命周期独立，空间并行
对切分出的部分，确立各自生命周期、主体、负责角色，权责对等
在非核心与核心生命周期之间建立沟通机制，通过树状架构组装为整体
重要推论
架构是树状的，因为核心生命周期按时间线性推进，非核心围绕核心形成树状
大自然是最好的架构师——道法自然
违背大自然规律的架构，人类必然付出代价
第5章 架构和树
树 = 核心生命周期为主干，非核心生命周期为枝干
树的增长 ≠ 进化；架构增长是"长大"，业务基因（目标）不变
业务进化（基因改变）→ 必须重新设计架构，不能在旧架构上修改
第6章 概念
概念是沟通的基础，无共识的概念导致巨大沟通损耗
每个概念背后对应一个生命周期
识别概念的本质 = 识别概念背后代表的生命周期和利益相关人
第7章 什么是抽象
个性是基础，共性从个性中抽取
抽象是发现共性生命周期的过程
抽象不当导致模型错误，导致架构失败
第8章 识别问题
识别问题的困难：容易看表象、容易被既有框架限制
识别问题的方法：找到问题主体 → 识别主体的生命周期 → 找到核心生命周期
问题主体的生命周期就是解决问题的边界
第9章 切分的原则
4条切分原则
必须在业务的核心生命周期上切分（不能破坏核心生命周期主体）
权责对等——切分出来的生命周期负责人必须能从该生命周期获利，否则无法落地
切分出来的生命周期不超出一个自然人的负载
切分是内部活动，对整个系统外部透明（不改变系统解决的问题）
架构切分总结
切分导火索：人的负载超限，时间不够
切分实质：对利益相关人的利益进行切分或合并，保证权责对等
切分结果：必须体现在组织架构上，架构才能落地
切分结果：一定是树状——分层越少越好，平衡树效率最高
多线汇报（矩阵架构）是权责不对等的信号，必须快速调整
第10章 架构与流程
流程 = 多角色为完成同一目标，按时间顺序协作的过程
流程本质是生命周期的表现形式
流程核心是业务的核心生命周期
流程把架构拆分后的不同角色串联起来，通过遍历架构树，重新组成业务生命周期整体
审批流程 = 权力下放的工具，体现组织架构树的遍历
流程梳理常见误区：被流程分支细节迷惑，忘记了流程背后是业务核心生命周期（只见树叶，不见树干）
第11章 什么是架构师
架构师的本质
架构师做的事：挖掘核心生命周期 → 剥离非核心生命周期 → 合理分配权责 → 预判未来增长 → 提前规划（战略架构）
架构师的独特性：社会分工职责是"给别人分工"
架构师必须具备调动资源的权力，否则只是"军师"（建议者），架构无法落地
架构师的报酬应由增长结果决定（正向反馈机制）
具备头衔的不一定是架构师，真正的架构师不一定有头衔
一个好的领导就是好的架构师
人人都是架构师
任何人一旦思考"如何做得更好、更多"，就在做架构思考
不识别核心与非核心生命周期，追逐不恰当方向，就会陷入时间焦虑
第二部分：软件架构（第12-27章）
第12章 什么是软件
软件历史 = 用机器模拟人的历史的延伸
冯·诺依曼结构 + 图灵机 = 可编程的大脑（电脑）
软件的本质：把人类的业务虚拟到计算机中，用虚拟人替代现实的人
软件是业务的使能者（Enabler）：把业务成本从高降低，不是创造新业务
计算机的成本受限于电力，只要电力充足，可以无限增长（"天空才是极限"）
软件打破了物理时空限制，极大提升生产力
第13章 软件的生命周期
软件生命周期的拆分
软件开发生命周期（非核心）→ 产出软件
软件运行生命周期（核心）→ 持续服务用户
软件访问生命周期（核心中的核心）→ 用户每次访问
关键推论
软件的开发可以外包，代码可以开源；但软件运维是核心竞争力，严防死守
迭代的本质：以核心生命周期为最高优先级，先实现业务核心，再不断丰富和拆分
版本并行开发：代码生命周期必须独立切分，避免不同版本的冲突
线上版本只有一个（必须保持核心生命周期连续），开发版本可以多个并行
第14章 什么是软件架构
软件架构要解决的两大问题
业务的问题：业务的主体、生命周期、核心/非核心拆分
计算机的问题：如何实现业务、如何跑起来、如何支持访问量增长
软件架构的定义
通过对软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式
包括：软件开发团队组织架构 + 代码架构 + 硬件部署架构 + 软件运维监控体系
核心推论
离开组织架构，任何软件架构设计都是纸上谈兵
架构不是进化，是长大——业务基因（核心生命周期目标）不变
架构拆分越细，并行度越高，业务长得越大
第15章 什么是软件架构师
软件架构师的困境
软件工程师天然专注于技术，而非业务——要成为架构师，必须克服对业务的恐惧
把"完成业务目标"当作自己最大利益，而非"完成自己的编码任务"
软件架构师的核心职责
深入理解业务组织架构和业务生命周期拆分
根据业务特点形成软件开发的业务体系（软件开发业务架构）
形成与业务架构匹配的软件开发团队组织架构
对软件进行架构拆分，匹配业务架构
关键认知
软件架构师对技术的态度：技术是工具，用来支撑业务，不是目的
技术人员对技术的态度：热爱并追求技术本身，对技术不平等
架构师必须是软件团队组织的领导，否则架构无法落地（拆分权力和执行权力都要有）
"不写代码就没资格叫架构师"这个说法是从软件工程师角度的误解
第16章 业务、架构和技术三者的关系
技术是工具，业务是目的，架构是桥梁
业务 → 架构（对业务生命周期的拆分）→ 技术（实现架构拆分）
技术人员和业务人员冲突的根因：两者话语权分散，权责不对等
重新发明轮子：对已有技术不理解背后的问题，导致重复创造
开源技术：他人的非核心生命周期拆分出来，以服务形式共享给所有人
第17章 软件研发
软件开发的核心活动（必须顺序推进）
确定业务需求
编码
测试
开发模式的两种类型
不信任工程师为基础，以避免犯错为核心（传统瀑布式）→ 大量文档、低效
信任工程师为基础，以工程师为核心（互联网敏捷式）→ 工程师掌握业务，高效
敏捷的本质：快速迭代并得到反馈——控制单次迭代周期足够短，快速发现并纠正错误
核心推论
业务团队和软件工程师合体 → 效率提升几个层次
只有软件工程师成为业务专家，写出来的软件才是靠谱的
先有人，有业务，才有软件——这个次序绝对不可以颠倒
第18章 软件的架构拆分
软件拆分的原动力
来源于业务本身的拆分所形成的组织架构（业务组织架构 → 软件架构）
每个专业领域自身遇到瓶颈 → 继续细分 → 树变高变宽
软件开发团队拆分的3种情况
多个业务团队对应一个软件开发团队 → 依赖混乱，扯皮不断（最差）
一个业务团队对应多个软件开发团队 → 沟通低效，最终同样混乱（次差）
一个业务团队对应一个软件开发团队 → 边界清晰，高效协作（最佳）
重要结论
软件开发团队的组织架构必须和业务团队的组织架构匹配成树状
业务组织发生变化，软件开发团队必须同步调整
架构一步到位是错误的：架构应随业务流量的实际增长而拆分，超前拆分增加复杂度和成本
第19章 如何写好代码
代码的4层架构
服务（Service）：专注用户访问通道，组合业务模型提供服务，严禁混入业务逻辑
黏合代码（Manager/Repository）：管理业务对象的生命周期，连接业务和存储
业务模型（Domain）：实现业务生命周期活动，包含全部业务逻辑（唯一有逻辑的层）
存储（Repository）：专注数据的保存和加载，严禁混入业务逻辑
业务逻辑内聚的好处
服务、管理者、存储代码只需连通性测试，不需要单元测试
业务代码可以独立做单元测试，不需要模拟上下文
存储设备可以按自身最小粒度工作，容易横向扩展
系统有问题时，定位快速：要么业务逻辑问题，要么访问环境问题
业务逻辑分散的危害
分散到服务：多用户共享同一通道，需求变更相互影响，权责不对等
分散到存储（SQL复杂化）：存储CPU不堪重负，无法横向扩展，只能纵向扩展（高成本）
代码重用原则
服务代码：不要重用（不同用户访问通道必须隔离）
业务模型：必须重用（所有服务的目标）
不同用户的访问通道不能共享，必须拆分
业务模型与DTO的关系
业务模型对用户不可见，通过DTO转换
DTO与视图保持一致，隔离用户需求频繁变化对业务模型的影响
第20章 单元测试
单元测试只测业务代码（有逻辑的部分）
访问代码（服务、管理者、存储）没有逻辑 → 不需要单元测试
需要大量Mock的测试，说明业务逻辑散落到了访问代码中
Mock维护成本高 → 最终形同虚设的根因就在此
结论：让业务逻辑内聚，单元测试自然简单，不需要Mock
第21章 软件架构与面向对象
面向过程：按时间顺序推进（图灵机本质，是计算机最擅长的）
面向对象：对应业务中不同生命周期主体（每个对象是一个生命周期）
二者不是对立关系：
内部实现（核心生命周期活动）：面向过程
整体组织（不同生命周期主体）：面向对象
面向对象的误区：脱离生命周期谈面向对象，导致对象设计混乱
第22章 软件架构与设计模式
模式 = 对常见问题的标准化解决方案
设计模式的本质 = 对某类生命周期拆分问题的模式化解法
设计模式和架构的关系：设计模式是局部架构拆分的固化，架构是整体的生命周期拆分
设计模式的误区：把设计模式当法典强行套用，不考虑背后的业务问题
第23章 软件架构与软件框架
框架 = 对业务模型或设计模式中稳定部分的封装，留有扩展余地
框架背后必有一个模式，背后有架构的拆分
框架无法单独运行；可以单独运行的叫服务
框架是本地引用，服务是远程调用
用好框架的前提：先理解框架解决什么问题（理解其背后的业务模型）
第24章 软件运维
运维的业务目标：保证用户访问生命周期不受影响
变更管理三步
隔离：建立生产环境隔离区，控制所有变更入口
监控：实时感知系统运行状态（类比ICU）
预警：基于历史周期性数据设定基线，自动报警，主动发现问题
变更的分类
被动变更：硬件老化、用户访问量突增（无法预测，需要冗余容错）
主动变更：软件/硬件/电力变更（主动变更引发的问题占线上故障2/3以上，软件变更占一半以上）
核心推论
运维工程师本质也是软件工程师，只是专注领域不同
云运维/第三方运维兴起 = 运维生命周期被拆分为非核心生命周期，形成新的行业分工
第25章 软件访问生命周期
用户访问路径的演进
直接硬件访问 → 操作系统 → C/S架构（客户端/服务器）→ 应用服务器 → 虚拟化/容器
规模扩展的两种方式
横向扩展（Scale-Out）：复制自己，增加集群（解决单点故障，且扩展成本低）
纵向扩展（Scale-Up）：增强个体能力（有上限，成本高）
计算机成本便宜后，横向扩展成为首选
集群（Cluster）的要点
路由（Router）：把用户请求按规则转发到集群内某台机器
负载均衡：路由必须定时检查机器健康状态和剩余容量
用户状态共享：集群内不同机器必须共享用户状态，否则集群对用户不透明
数据中心（Data Center）
多数据中心 = 集群的集群，按地理位置分布
解决问题：减少网络延迟（就近访问）+ 防止单数据中心故障导致全局不可用
路由策略：按用户来源地理位置路由到对应数据中心
第26章 软件架构与大数据
大数据的本质
不是数据有多"大"，而是对关系型数据库处理方式的颠覆
大数据 = 针对大量数据集的快速处理技术（解决T+1实时性不足的问题）
做好大数据的路径
理解数据 → 理解行为 → 理解业务 → 理解业务目标 → 明确业务主体 → 理解生命周期 → 理解架构拆分
核心推论
大数据的焦点不在"大"，在"数据"，更在数据背后的业务生命周期
不理解架构拆分，不理解生命周期，无论用什么数据处理技术，都无法形成有效决策
业务生命周期的架构拆分，是理解业务数据的基础
第27章 软件架构与建筑架构
相同点
都是为人服务，解决人类生命周期问题，形成社会分工
都以增长为目的，都形成树状架构
不同点
第三部分：软件架构的应用（第28-33章）
第28章 交易
交易的出现：分工导致交换，货币降低交换成本
企业的实质：把多个人的生命周期活动整合起来，通过交易完成增长
软件对交易的影响：把交易的时空限制打破，降低交易成本
企业的核心：持续为用户创造价值并完成交易
第29章 产品
产品 = 满足特定用户生命周期需求的解决方案
商品 = 参与市场交换的产品
产品的生命周期：产品定义 → 上市 → 销售 → 退市
识别产品的方法：从用户的核心生命周期出发，找到用户最需要解决的问题
产品列表、产品详情、商品规则：都是围绕用户购买生命周期进行的架构拆分
第30章 用户
用户的生命周期：注册 → 活跃 → 沉默 → 流失
用户的核心利益：用最少时间最低成本完成自己的核心生命周期活动
客户的出现：用户中需要频繁交互、深度服务的子集
用户识别：基于唯一标识（账号体系）贯穿用户整个生命周期
第31章 订单
订单 = 交易双方对交易内容的契约，记录交易生命周期的状态
订单的生命周期架构拆分：
创建 → 支付 → 履约 → 完成 / 取消
订单是业务核心生命周期的载体
订单支付 = 独立的支付生命周期（可拆分为独立服务）
第32章 交易系统
企业架构拆分路径
CEO（一个人）→ 业务量增大 → 按核心生命周期拆分 → HR/市场/产品/订单/支付/结算等团队
组织架构变化 → 软件架构随之变化
软件系统建模步骤
识别业务核心生命周期（找主干）
识别业务组织架构（找树的结构）
用代码实现业务模型（虚拟化组织架构）
围绕核心生命周期实现用户访问通道
数据持久化（记忆外存化）
服务的粒度原则
以业务生命周期为单位，一个业务生命周期对应一个服务
服务粒度过大：耦合严重；粒度过小：调用链路过长
用户系统的拆分
用户注册/登录/信息维护 → 独立用户服务
用户授权（权限）→ 独立权限服务
不同业务线的用户访问通道必须隔离
第33章 事务
事务 = 多个操作构成的原子单元，要么全成功，要么全回滚
数据库事务的滥用：把所有操作堆进一个数据库事务，导致锁范围过大、性能差、扩展难
正确使用数据库：数据库只负责存储，事务只管自身存储边界
服务调用的事务问题：跨服务的一致性不能依赖数据库事务，要用最终一致性/补偿机制
最终一致性思想：允许短暂不一致，通过异步对账、补偿来保证最终正确
全书核心观点速查
架构篇
架构的目的是增长，通过切分生命周期达到并行
架构结果必须是树状；分层越少越好
架构的执行（组织架构落地）比设计更重要
架构师 = 具备权力的业务领导，而非只有头衔的技术顾问
软件篇
软件 = 虚拟人，模拟现实业务
软件架构的核心是业务的核心生命周期识别和拆分
代码架构：业务逻辑必须内聚在业务模型层，服务和存储不能有业务逻辑
软件开发团队的组织架构必须和业务团队组织架构一一匹配
方法论
遇到任何问题：先找主体 → 找核心生命周期 → 分析拆分 → 确定权责 → 建立组织
技术是手段，业务是目的；不理解业务的技术人员无法做好架构
迭代的前提是先实现业务核心生命周期，宁愿粗糙，不要跑偏
全书金句
架构产生的本质是人类对时间的恐惧。
架构是支撑业务长大的，而不是进化的。
离开了组织架构，任何软件架构设计都是纸上谈兵。
具备头衔的架构师不一定是架构师，真正的架构师不一定有架构师的头衔。
一个好的领导就是一个很好的架构师。
软件的开发可以外包，运维才是核心竞争力。
大自然是最好的架构师，她所做的只是让每种生命能够顺应自己的生命周期。
只有软件工程师成为业务专家，写出来的软件才是靠谱的。
先有人，有业务，才有软件——这个次序绝对不可以颠倒。
大数据的焦点不在"大"，在"数据"，更在数据背后的业务生命周期。
做好内聚的前提是去发现生命周期及其主体。
不理解人类社会本身，计算机和软件相关的技术是很难掌握好、应用好的。