具体描述
我们总是喜欢借鉴别人的架构实践，参考别人的架构图，但体会过的人都知道，由于各家公司的行业背景、发展情况、人力资源都不同，所以真正意义上的架构借鉴难度很大。 《聊聊架构》希望揭开事物的外在“表皮”，再现架构深层之理，向读者揭示最本质的架构之道。
架构是如何运作并影响人们的日常生活的，在软件行业中架构是如何运作的？架构又是如何指导代码编写的，如何把架构应用在软件工程实践上？带着这些疑问，《聊聊架构》通过大量的实例一步一步揭示出架构背后的原理，以及架构在软件行业的发展，并通过企业实例来展示软件架构的实际应用。《聊聊架构》没有高深的词汇，不仅适合IT 从业人员阅读，也适合其他行业的人士阅读。尤其对于想从事架构工作的人而言，是一本不可多得的参考材料。
作者简介
目录信息
第一章 生命周期 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
· · · · · · (收起)
读后感
本书涉及软件开发大部分重要环节，从需求一致到运维，也就是软件的全生命周期。整本书分为两个主要的部分，前半部分讲述作者对于软件生命周期各环节相关概念的理解和感触，后面部分章节则是前面思想在一个商城中的应用与思考。前半部分含金量较高，有很多作者自己的见解和思考...
可能很多人会以为《聊聊架构》是纯技术类的，实际上呢？用最不技术的方式讲技术，不仅仅是别出心裁，更是大道相通。作者用了相当大的篇幅，基本上把康威定律讲透了，如《人类简史》所述，最终所有的工作都是人来实现的，面对的也是人，那么受限制的是人，所以我们考虑的系统的...
哎…说聊聊，更像是漫谈，整本书像是一本散文集，每个篇章都是一个故事，整体缺少一个主线。说白了，看完觉得空空。也许是我自己才学疏浅，没明白作者想要传达给读者怎样一种思想，或者要解答怎样的困惑。 慕InfoQ之名而来，作者是位大牛，但是似乎并不太擅长知识体系的梳理输...
本书涉及软件开发大部分重要环节，从需求一致到运维，也就是软件的全生命周期。整本书分为两个主要的部分，前半部分讲述作者对于软件生命周期各环节相关概念的理解和感触，后面部分章节则是前面思想在一个商城中的应用与思考。前半部分含金量较高，有很多作者自己的见解和思考...
很有诚意的一本书，能感受到作者很用心，通读之后建议以下两类读者阅读： * 和 IT 对接的「业务人员」。 * 和业务对接的「技术人员」。 有书友说本书罗嗦，这也是本书的特色之一，作者在尝试用生活中的示例说明技术。作为读者对示例不一定认同，但是作者的方法值得借鉴，特别是...
用户评价
我对《聊聊架构》这本书抱有很大的期待，希望它能为我提供一个全面而深刻的理解，让我能够真正掌握架构设计的精髓。我希望书中能够提供一些关于如何平衡技术选型与业务需求之间的关系的思考。在很多项目中，我们常常会面临选择哪种技术栈、哪种数据库、哪种消息队列等等艰难的抉择。这些决策往往会对项目的长期发展产生深远影响。我希望书中能探讨这些技术选型背后的考量因素，例如成本、成熟度、生态系统、学习曲线等，并提供一些如何系统性地进行技术评估的方法论。我希望它能帮助我避免那些“看上去很美”但实则并不适合当前场景的技术选择。同时，我也对书中可能涉及到的关于架构评审和度量的部分感到好奇。如何对一个已有的架构进行有效的评审，找出潜在的问题和改进点？是否有量化的指标来衡量一个架构的好坏？这些问题对于持续优化和演进架构至关重要。我希望这本书能够给我提供一套完整的“架构工具箱”，让我不仅能设计出好的架构，还能对其进行持续的评估和改进，从而真正地为项目的成功保驾护航。
作为一名技术实践者，我深知一个好的架构并非一蹴而就，它需要团队的共同理解和协作才能得以实现。《聊聊架构》这本书，我希望它能触及的不仅仅是技术层面，更能包含一些与团队和沟通相关的要素。架构设计往往不是一个人能独立完成的，它需要与产品经理、项目经理、其他开发者甚至运维人员的密切配合。书中是否会探讨如何有效地与不同角色的人沟通架构设计理念，如何让团队成员理解并认同架构的价值？一个被团队普遍接受和理解的架构，其生命力会更强，执行起来也会更顺畅。我希望它能提供一些关于如何建立统一的架构认知，以及如何处理架构分歧的建议。此外，关于架构文档的撰写，也一直是我头疼的问题。如何用简洁明了的方式记录架构决策，并使其易于理解和维护？书中是否会提供一些关于编写高质量架构文档的指导？我希望这本书能让我明白，架构的成功，不仅在于设计的巧妙，更在于沟通的有效和团队的协同。毕竟，再完美的蓝图，如果无法被准确地执行，也只是纸上谈兵。
我一直认为，所谓“架构”，并不仅仅是那些绘制在白板上、看起来颇为复杂的框图，也不是那些写在文档里、令人望而生畏的设计原则。它更像是一种思维方式，一种在纷繁复杂的业务需求和技术限制中，寻找平衡与最优解的艺术。我期望《聊聊架构》这本书能够深入探讨这种思维方式的形成过程，以及如何培养这种思维能力。我希望它能不仅仅停留在“是什么”的层面，更能触及“为什么”和“怎么做”。例如，当面对一个全新的项目，我们应该如何着手思考其架构？是在项目初期就投入大量精力去设计，还是在迭代过程中逐步演进？不同的选择又会带来怎样的后果？书中是否能提供一些关于架构演进策略的见解？我特别想知道，在敏捷开发日益盛行的当下，架构设计应该如何与快速迭代的需求相协调，而不至于成为阻碍项目进展的绊脚石。此外，书中能否也提及一些“反模式”，也就是那些看似合理但实则会给项目带来隐患的设计倾向，并提供避免这些误区的建议？我深信，了解“不能做什么”和“为什么不能做”同样重要。一个好的架构，不仅能支撑当前的需求，更能为未来的发展预留空间，具备一定的弹性与可扩展性。我希望能从这本书中学习到如何构建这样的“弹性”架构，使其能够从容应对变化。
在技术日新月异的今天，软件架构的边界似乎也在不断模糊和扩展。从最初的单体应用，到微服务、事件驱动，再到云原生和Serverless，每一种新的范式都带来了新的挑战和机遇。我非常好奇《聊聊架构》这本书是如何看待这些发展趋势的，它是否会梳理这些架构演进的脉络，并对其背后的驱动力进行分析？我希望书中能针对不同类型的架构风格，给出一些相对客观的优劣势分析，以及在何种场景下选择哪种架构更为合适。例如，微服务架构固然强大，但其复杂性也显而易见，是否书中会有关于如何管理和运维微服务集群的实践经验分享？对于那些刚刚接触微服务，或者正在考虑从单体迁移到微服务的团队来说，这无疑是非常宝贵的指导。同时，我也对书中可能涉及到的非功能性需求，如性能、可靠性、安全性、可维护性等，在架构设计中的体现感到浓厚兴趣。这些往往是决定一个系统是否“可用”和“好用”的关键因素，而它们的实现，很大程度上依赖于架构的合理性。我希望这本书能让我明白，如何在架构层面系统性地解决这些挑战，而不是仅仅依靠一些零散的技巧。
作为一名在这个行业摸爬滚打了几年，却总感觉自己对“架构”这个概念停留在模糊不清的状态的开发者，当我看到《聊聊架构》这本书名时，内心涌现出了一丝期待，又夹杂着一丝不安。期待是因为我迫切地想找到一本能够真正帮助我理清思绪、构建清晰认识的书；不安则源于过往阅读大量技术书籍的经验，很多时候它们要么过于晦涩难懂，要么流于表面，无法触及到核心。我希望这本书能够像一位经验丰富的前辈，用通俗易懂的语言，循序渐进地为我揭示架构的奥秘，而不是堆砌一堆高深莫测的术语和抽象的概念。我特别希望它能解答我心中一直存在的疑问：在实际的项目开发中，架构到底扮演着怎样的角色？它如何影响着项目的生死存亡？那些被奉为圭臬的架构模式，在真实世界的应用场景下，真的有那么神乎其神吗？我渴望这本书能提供一些接地气的案例分析，让我看到理论是如何落地生根，最终开花结果的。如果书中能穿插一些作者在实际工作中遇到的挑战和解决方案，那将是再好不过了，因为我深知，理论与实践之间总是有着一道难以逾越的鸿沟，而跨越这道鸿沟的经验，往往比纯粹的理论知识更为宝贵。我希望这本书能给我一种“豁然开朗”的感觉，让我能够带着更自信、更清晰的视野，去审视和设计我将要参与或主导的系统。
啥也不是。
能打开思路，很有启发性，推荐阅读
理解主体的生命周期，拆分非核心生命周期
登高才能望远。概念和抽象的区别，架构在于执行在于生命周期的拆分，用户访问生命周期对应业务逻辑，单元测试只适用于业务逻辑，事务要放到业务逻辑做（复式记账），这些都学习了。
适合初级
