郭冬白的架构课
2024-10-12 10:58:27 0 举报AI智能生成
郭冬白的架构课是一门深入浅出、系统全面的架构师成长指南。这门课程涵盖了软件架构设计的核心内容，包括高性能、高可用、可扩展的架构设计原则，以及架构师的核心技能，如系统建模、需求分析、技术选型和架构决策等。课程采用多媒体教学方式，结合案例分析和实践项目，帮助学习者快速掌握架构设计的精髓。此外，课程还提供了丰富的参考资料和实践指导，为学习者提供了一条从初级架构师到高级架构师的成长路线。无论是对软件架构感兴趣的初学者，还是希望提升技能的专业架构师，都能在这门课程中找到有价值的知识和技巧。
作者其他创作
大纲/内容
真正的架构师成长，主要靠思考力的提升
怎么培养自己作为架构师的意图
使用演绎法来寻找架构原理，而不是归纳法
我会穿插一些基本的架构方法、思维工具和建模技能，来帮助你提升架构素养。
课程中会有大量案例，都是根据我的真实经历加工而成的。
培养架构师的三种方法
目标
架构师必须保障整个架构活动有且仅有一个正确的目标
法则一
人和
法则二
资源
架构师需要在资源的制约下去最大化商业价值
法则三
天时
架构师选型必需要考虑到所依赖的商业和技术模块的生命周期
法则四
行为
法则五
地利
法则六
模块一：六大生存法则
从大型架构项目实施层面上考虑，你作为架构师必须要关注和干预一些重要的节点
然后在这个过程中去创造自己的增量价值
概念
环境搭建
目标确认
可行性探索
架构规划
项目启动
阶段交付
全面上线
复盘
架构活动的八个节点
模块二：价值创造
单个模块的设计能力
解决横向问题的能力
解决跨领域冲突的能力
全局性技术决策的能力
以及通过技术带来生存优势的能力
五种能力
p class=\"p1\" style=\
逻辑思维
批判思维
逆向工程
反思
跨越边界
数据分析
提升思考质量的方法
模块四：思考力
如何建立战略意图
子主题
开篇词｜没有战略意图，就成不了一个顶尖的架构师
制定并且交付架构方案的过程。
架构活动
1.要和企业目标一致
2.与商业、软件环境相匹配
3.并且还需要满足各种资源的约束条件
满足
最大化商业价值，以及最大化目标用户满意度的方案
最终，你还要组织技术团队交付这个架构设计方案。
步骤
首先要做的就是确定架构设计方案
要在这些方案中找到那个能够最小化资源和成本
架构方案
组成
商业环境
架构活动消耗的资源
产出的商业价值
无法决定研发项目的选择、优先级、排期、代码实现方式等等。
研发活动
1.中间白色部分是架构师的决策领域
架构活动消耗的资源（商业资源、研发资源等）和成本（时间成本、机会成本等）
不受架构师所控制的部分研发活动
两者会综合影响架构活动的最终结果
总结
输入
架构活动可能带来的短期和长期的商业价值（公司的规模、效率和体验等）
架构活动为目标用户群体所提供的直接价值
输出
2.黄色部分指架构师的输入和输出部分
如竞争、市场、监管等
企业所处商业环境
如交互设备、sensor 网络、计算环境、外部的数据源等
企业的内部技术环境
企业和团队的文化环境
环境在很大程度上会影响架构方案的选择和实施路径
但同时也是大部分架构师最容易忽略的考量因素
注意
3.蓝色部分指架构师的工作环境
分类
架构师的全部活动
过程
确定目标应该是架构规划的起点
原因
确保最终的架构活动能够为你所在的团队或企业带来价值
否则目标错了，你的项目永远也没办法成功
结论
学会如何去理解和干预这个目标
注意:
所有的活动都要消耗资源且最终要创造价值
背景
如何通过架构活动来最大化你所贡献的商业价值的
否则资源不足或者是消耗太快，你的项目也同样无法成功。
做法
有了目标，有了足够资源，如果你还有正确的行为
也就是正确的做事方式，那你就能逐步逼近正确的架构方案，并且指导团队完成它
做成一件事情，如果周边条件成熟，环境好，那么事情就会进行得很顺利
反过来，如果条件不成熟，或者你逆势而为，那就会很艰难
架构活动也一样，影响它成败的要素也有天时、地利和人和。
正确的行为
指的是商业环境和技术环境的变化趋势
是什么
环境复杂多变，那么看清楚变化趋势的本质
就可以让我们的架构决策顺势而为，借助于环境的变化来成就我们的团队、企业
如何选择最有利于架构师职业发展的文化环境，最大化你的成长
如何做
架构师需要与多个研发团队协作，因而理解研发方的核心诉求就尤为关键
输入端
架构师产出方案的最终评判即目标用户的长期满意度
输出端
架构活动中涉及的人主要是研发人员和目标用户
深度洞察用户的人性就是保证架构活动成功的关键所在
六个要素
法则一:目标
法则二:人和
法则三:资源
架构师选型必须要考虑到所依赖的商业和技术模块的生命周期
法则四:天时
法则五:行为
法则六:地利
架构师的六大生存法则
六个法则的顺序跟我们刚才提到的影响架构活动成败的六个要素的顺序不完全一致
原因在于我是依照法则本身的重要性进行排序的，而不是要素的结构
六个要素和六个法则的关系
01｜模块导学：是什么在影响架构活动的成败？
所有的架构规划必须有且只有一个正确的目标
而且它必须与公司的战略意图相匹配，这是你架构设计的起点
否则，系统就会变得复杂和无序，缺少结构性。
第一条生存法则
一半以上的架构活动在发起之前都没有明确的目标。
这种架构活动执行到最后，多个协同模块之间必然是一个散乱的结构
如同所示
如果在初期就有一个明确的目标，那么做到最后
子模块和初期目标就会是大致对齐的，同时也会最大化对目标的贡献。
架构活动为什么需要目标？
技术同学对于先进技术的强烈好奇心
开发者的个人利益
以及信息沟通不畅
技术上：目标缺少全局视角
业务上：目标太多、不明确
目标缺失的两大根因
做架构越久，越来越发现决定架构形态的非技术因素占很大比重
现在一般都从ROI（投入产出比）的角度出发来看待项目
而另一个项目短期成本是10，但收益也只有10，我会选择前者。
是否有商业价值，是否与公司战略方向一致。
有些项目，可能能带来短期价值，但是与整体目标不一致，这种反而是一种消耗。
如何判断项目重要性
判断一个项目的重要性
1.根据公司现阶段状况，如何发力
比如小公司，就会想着如何提升效率，如何快速推动0-1探索
思考力分配
02｜法则一：为什么有些架构活动会没有正确的目标？
首先，要用企业的战略意图去鉴定架构活动目标的正确性。
你可以与架构项目的发起人反复沟通，陈述你的理由
建议他去寻找另一个更接近战略意图的目标。
接着，如果目标与战略意图不匹配，那么你要试图影响甚至是改变这个目标
如果目标与战略意图匹配，那你要看看是否存在一个更合理的目标，可以让企业能够更快地逼近战略意图。
所谓的一个架构活动目标和企业战略意图相匹配
指的是架构活动对一组 KPI 的贡献，需要与对表达企业战略意图的 KPI 形成增强关系。
简单来说，就是你的 KPI 对战略意图是有正向贡献的。
第一，什么才叫匹配呢
一般来说，一个架构活动的发起如果有比较充分的理由和论证，那么架构活动的目标往往就会是正确的
但你肯定会遇到目标不正确的架构活动，这个时候，你作为一个架构师就要有义务指出来。
第二，如果发现目标不正确，那该怎么办呢？
两个问题
如何寻找正确的架构目标？
1. 新方案的实现成本有多少？
2. 新方案上线后带来的短期价值有多大？
3. 这个新方案是否可以全面替代现有方案？
4. 全面替代的实施成本有多少？
5. 全面替代之后，这个新方案带来的长期价值是什么？
6. 如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？
关于技术驱动的目标
首先，想办法反馈这个情形，耐心解释给当初的决策者，请他来做取舍
你可以用评分卡模型对项目的优先级做个判断
如果你自己不确定，也可以邀请资深的同学给项目打分，但是注意要排除掉与他利益密切相关的项目
其次，你自己做个取舍优先级，想办法通知到决策者
你需要清晰表达你取舍背后的思考逻辑，并邀请相关的利益方参与辩论
如果他们的输入合理，那么你可以调整取舍
如果输入不合理，那么你可以选择拒绝他们的要求
可以尝试自己拿下取舍权
比如你可以采用类似设计模式中的策略模式，把一个或多个业务尝试隔离在策略实现中。
每次业务尝试对主流程不产生影响，每个尝试逻辑都封装在单个策略中
通过技术手段来做延迟或者是隔离决策
关于业务项目的目标
关于架构目标的决策，对于一个人或一个团队的影响是巨大的
所以当你有了一个正确的关于架构目标的决策，要知道这只是一个起点
你还要认真思考这个决策的实施路径，让大家团结在正确的架构目标上，而不是你自己一个人举着架构目标，变成孤家寡人。
技术
架构师该如何影响架构目标呢
无论在什么时候，都要有勇气去做正确的架构决策。
如果目标太过超前怎么办？
03｜法则一：如何找到唯一且正确的架构目标？
架构活动需要尊重和顺应人性
第二个生存法则
假设一个人同时存在 5 个需求，需求 1 和需求 2 已经被满足了，那么这两个需求就不会再诱发动机
而需求 3、4 和 5 没有被满足，它们会同时诱发各自的动机
但由于需求 4 和 5 诱发的动机被需求 3 所压制，因而最终是需求 3 诱发的动机，在组织和驱动这个人整体的意识和行为。
解释
例子
我们可能同时并行存在着多个需求，这些需求之间并不存在依赖或层次关系
如果这些需求得不到满足，那么它们各自会诱发动机
但动机有优先级，且具备抢占性质。所以任何时候，只有一个动机在主导着整个人的意识和行为。
不是需求有层次，而是动机有优先级
人有且只有一个主导动机
这个动机由人的内在需求所驱动，并独占且主导这个人当前的一切意识和行为
直到这个动机背后的需求被完全满足之后，更高层次的动机才可能进入主导位置
马斯洛理论的实质总结
马斯洛所讲的动机不仅是有优先级的，而且是跃迁的，对人的行为的组织和驱动而言是独占的
这就是你从源头深度探索一个理论时，能得到的别人得不到的东西
动机跃迁
安全感是心理上的诉求，不等于人身安全
安全是生理上的，仍属于刚才提到的生理需求的一部分
安全和安全感的区别
在广义上指的是人们试图寻找的生活中的安全和稳定性
表现为更倾向于熟悉的、常规的、有结构的、可控的、已知的、可预测的和安全的事物
心理安全感的含义
主要来自于一个人的成长过程
一个人从出生起，父母会为孩子就会提供熟悉、常规和有结构的日常生活
这种安全感也在随后的成长中逐渐扩展到了相对可控的、已知的、可预测的，以及相对安全的生活和工作环境中
心理安全感的获得
在最底层的生理需求得到满足之后，心理安全感这一需求诱发的动机就会成为主导人意识的主要动机
在生理需求之下是心理安全感
有底气的自尊也一样，这是发自内心的需求，不是说大家认为你应该有自尊你就有自尊了
而是你内心认为自己具备这种自尊，那你才会真的具备
是自尊和被尊重的需求
马斯洛讲发自内心的需求指的是自己真正想要的，而不是别人眼里的成功
最后是自我实现
动机抢占
两个重点
1.最基本的生理需求
2.到心理安全感
3.再到群体认同感
4.然后是内在有底气的自尊
5.最后到自我实现
理论的跃迁
如果这些需求没有被满足，它们就会刺激出人的动机，去满足这些需求
但这些动机并非同时生效，因为任何时候都只有一个主导动机在支配着我们整个人的感官、意识和行为
这些动机依次出现的顺序
当生理需求得不到满足，那么源于生理需求的动机 1 就会处于主导地位，并且会屏蔽其他动机
只有生理需求得到满足了，那么处于生理需求之下的、未满足的安全感，才能诱发以获取心理安全感为目标的动机，然后成为主导动机
马动机跃迁理论的核心描述和具体应用
如何理解马斯洛的理论？
花了这么长时间来研究这个理论，就是因为它对软件研发和架构活动具有实际的指导作用
软件是由人类所构造的一个虚拟的存在，而这个构造过程，是靠一组研发人员共同协作完成的
既然马斯洛的模型适用于一切人类活动，那么这个模型当然也可适用于与软件构造相关的架构活动
作为一个架构师，以马斯洛的理论来指导架构方案的设计和组织架构活动，会让你的设计尊重和顺应人性
避免因忽略人性而带来巨大的失误，甚至可以帮助你找到一个突破性的解决问题的视角
学习的原因
深度理解和尊重用户的做法，就是设计思维的精髓所在
到底是被动地迭代方案，执着于填补设计的漏洞；
同时忘记现有的技术方案的强大，把关注点放在深度理解用户、解决用户的痛点上
进而拓展技术设计空间，找到更完美的技术路径。
还是从共情用户的角度出发，脱离现有技术方案的束缚
看问题视角
04｜法则二：架构师为什么要学习马斯洛的需求理论？
架构设计必须符合人性，而在架构活动中，与“人”相关的主要就是研发人员和目标用户
所以不但技术先进，而且附带了很多海外同行们还没有开发出来的业务能力
迁移的好处
完全忽视了小公司里研发团队的心理安全感需求。
失败的好处
失败案例
没有人性的技术架构，就没有生存空间
在这个项目里的人，他们的升职、团队招聘、晋升、年终奖、股票都已经和这个项目牢牢绑定
对于他们而言，任何动摇这个项目稳定性或者是削弱这个项目价值的言论，必然会伤害到他们的自身利益和心理安全感
当一个架构方案有数千人参与，那么这个方案随着时间已经逐渐演变成了一个运动
一个运动，由这个运动自身而产生的惯性，已经不受一两个决策者控制，大量的参与者已经为这个运动注入了持续的生命力。
根本性原因
越是大型的架构方案，就越要在早期去讨论它的方案可行性，而且要尽量试图要从批判和否定的眼光去看待它。
这种讨论越早越好，涉及的利益方也越少越好
而不是放在详细规划已经完成之后，甚至是项目已经了启动一小半了才做评审
额外认知
为什么会有人设计没有人性的架构？
一个人应该分到几个微服务，还是几个人一起维护一个微服务呢？
每人至少一个，而且还得是核心服务
这样每个研发都不用担心他的工作安全，因为没有人能够轻易取代他
不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
答案
划分微服务的粒度不仅需要考虑研发的人性
还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等
另外角度
问题
1. 粒度小，单个服务可以紧贴业务快速迭代；
2. 去中心化组织和部署结构，减少不必要的协同；
3.数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
4. 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
5. 服务本身的独立部署能力使得容错和容量弹性最大化；
6. 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。
微服务的核心价值
想想看，你自己对业务有深度理解，能够和业务同频率迭代
你什么时候想改代码就改代码，不需要协同，改好了就上线
你自己一个人改自己的商业逻辑和数据模型，根本不需要担心其他人祸害
其中第 1、2、3 项是人越少越高效的，最高效的状态就是一个人。
服务本身对公司的价值太大，它上面承载的业务量
对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本的时候
或者是从性能角度来看，服务无法拆分，它得复杂度大到可以支持多个研发维护的时候
唯一能够支持多名研发维护同一个服务的理由
分析微服务的核心价值
如何设计微服务的粒度？
05｜法则二：研发人员的人性需求是如何影响架构活动成败的?
拼多多对用户人性的理解，远远超越了其他同时期的电商玩家。
我们的核心不是便宜，而是满足用户占便宜的感觉
人性中占便宜的需求，在马斯洛的需求层次中应该更接近生理需求层次。
也就是说，一旦这个需求被触发，它将抢占其他一切动机，成为主导
而你的所有意识、行为都是在满足这个主导动机
分析
如果一个公司，能锁定目标人群及其心智
那么对于软件架构师而言，你就有了一个确切的技术问题和研究方向
作为一个架构师，理解这个人性有什么意义呢
图中的每条连线上都有一个角标，“+”号表示一个前项因素的增长，箭头指向后项。
如果前项的增长会带来后项增长，那么箭头上也用“+”号表示。
你会看到整张图上都只有“+”号，这就代表整个平台机制形成了正循环。
也就是说，随着时间的推移，价值在不断放大
这是系统论的正反馈循环，也就是大家经常提到的飞轮效应
1. 通过放大占便宜的心智，拼多多省下了巨大的营销成本，获得了大量的免费流量。
2. 这些免费流量加入到已有的具备相同心智的用户中
3. 这些用户的需求变成了订单。
4. 大量的订单变成了供给端的集中采购优势
5. 这个采购优势也吸引了大量能提供更高性价比的供应商。
6.这些供应商和现有供应商在平台不断提升性价比的平台机制之下，为用户提供了大量极致性价比的商品。
7.这些商品能够更好地满足用户占便宜的心智，所以也会持续帮助平台获取更多的免费流量
循环的具体流程如下：
也就是拼多多在逐渐培养放大的 C2M 模式
是有规模效应的新商家的代表。
其中一个输入是集中采购
另一个是普通的平台商家，是平台老商家的代表
两个输入
而平台机制模块决定什么样的商家将被激励和选择性放大，最终会输出什么样的商品。
一个输出
平台机制模块的设计决定了整个平台是否能够维持增长。
平台机制模块分析
示例图
一个平台的定位，也就是满足用户占便宜的心智，反向选择了用户人群
然后在这些人群的共性需求中建设了自己的供应链，从而形成正反馈闭环。
拼多多的飞轮效应。
思考该如何通过技术放大以占便宜心智为主的马太效应。
你既要脱离现有技术方案的束缚，同时也要忘记现有技术方案的强大，在更大的空间搜索这种技术突破。
那你更多的注意力就要放在系统的弹性设计上
放在头部商品和尾部商品的分层管理上、CDN 分发机制上
也要放在订单管理和供应链效率优化上，甚至是整个平台的事件流的管理、分析和可视化上。
如果你要关注如何通过技术充分放大马太效应
这种从流量到用户需求、到订单、到供应链的优势
也都需要不断提升数据、分析、算法的效率，从而保障头部商家的生存，以及保障用户的体验。
从技术的长期战略上
这种单一用户心智所溢出的流量、需求，以及订单如何最大化转化
也是个非常值得长期投入的技术方向
从更长远来看
角度
软件架构师的思考
一个架构师，如果你能尽早看懂看透你公司的用户心智，
那么你就可以在技术上提前布局，从用户思维出发
扩大你的技术搜索空间，最终为公司创造更大的价值
拼多多案例传递的核心
缩短认知差距
远离邪恶的心智
案例番外篇
06｜法则二：拼多多是如何通过洞察用户人性而脱颖而出的？
作为一个架构师，必须要在有限的资源下最大化架构活动所带来的商业价值
第三个生存法则
讲一个企业是以什么样的方式赚钱的
比如电商行业，有自营和平台两种不同的商业模式
商业模式
从现金收入的视角看价值创造的过程
你每天忙碌的工作，从企业的收入上来说，可以为公司带来什么样的短期和长期现金和其他收入
那么对这部分收入的量化，就是你创造的商业价值
简单来说，商业价值就是帮助公司获取商业收入。
例如
商业价值
实现一个商业模式
提升一个商业模式的效率
加速一个商业模式的收敛速度
技术人员创造的商业价值
什么是商业模式？什么是商业价值？
在一个领域做了很多年的研发人员、架构师，甚至是团队主管
都不太清楚自己开发的模块和所在领域的商业模式是什么
不知道商业模式，就没法主动创造商业价值，你的日常工作很可能只是不断被动实现需求。
为什么要理解
对所在行业的商业逻辑的数学表达，也就是我们常说的 KPI 的逻辑。
一个商业模式的技术表达公式
总收入 = GMV * Commission
网站的交易额越大，抽成就越多。网站规模越大，总收入就越多。
比如说天猫这个电商平台，它的主要收入来自于交易抽成：
比如说你负责天猫平台的一个由算法驱动的购物频道，那么你们的商业模式可能是这样的
GMV= 流量 * 转化率 * 平均订单金额
不同的细分领域，每个领域的商业模式，就会分解成不一样公式了
GMV= 活动参与次数 * 平均计划销售额 * 计划达成率
如果你负责某个垂直行业的大商户运营团队，那么你们的商业模式可能是这样：
GMV= 动销商品数 * 订单数 * 每订单件数 * 件单价
通过撬动更多的商家参与营销活动，来提升动销商品数和订单数
通过满多件打折等营销方式，来提升每个订单的商品件数；
通过更多的功能和商品的可选配置，来提升每件商品的单价。
目的
如果你负责商品团队，那么你们的商业模式可能是这样的：
理解你所在的企业或团队的商业模式
公司高层选择了言听计从的乖乖虎，那么这个乖乖虎就会以他最擅长的方式来获取部门赖以生存的收入，也就是公司的拨款
所以他们只有一条路，就是无时无刻讨取高层的欢心。
整个部门都要靠公司高层调拨的预算来求生存
一个以客户为导向的团队，他们的首要目的不是听从上司的声音
而是去倾听客户的声音，从客户的需求中寻找自己能够创造商业价值的地方。
所以这样的团队，绝不会靠公司的拨款过日子，他们的收入必须源自为客户创造的真实的商业价值。
部门的资金来源逆向选择了人才及其行为。
一个业务部门而言，存在不一定合理，只有提供稳定商业价值的存在才是合理的。
理解你在自己所处环境中创造的商业价值
你必须在工作环境中找到创造价值的方式，这样才能保障自己一直被需要，也能保障未来的收入
每个人都要有自己的商业模式
你要为公司、部门或团队提供可量化的增量价值
就是你通过工作所创造的价值，是在社会提供的平均价值之上的。
因为那时候开源的微服务框架还不够成熟
2010 年之前，如果你是一个做微服务框架的高手，那你的增量价值就非常大，一个人能顶十个甚至一百个研发
但到了今天，如果你还是单兵作战，擅长写微服务框架，那跟开源的 Spring Framework 相比，你提供的增量价值可能就是一个负数了
因为团队剩下的同学还要花时间来学习、使用和维护你写的框架，公司也要为这些同学付出工资成本
第一是增量价值
对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。
如果你不度量自己的增量价值，那就无法确保自己处在价值创造的前沿
GMV= 动销商品数订单数每订单件数 * 件单价
把自己的工作放到我们刚才讲的公式里去。假设你是做商品相关的技术，那么：
你需要度量的是，你的工作对公式中的某一项或某几项会起到什么促进作用。
有了这些度量，你就会不断调整自己的知识和技能，不断搜索新的突破口，最终为公司创造源源不断的价值
而你的这个能力，会被周围人以及领导注意到，也会因此获得更多可以施展才能的机会与场景。
你不仅能得到马斯洛所讲的有底气的自尊，还能得到从目标到实现手段的完整闭环。
这个时候，这个技能就会成为你的一个核心技能。
阶段
怎么度量自己的增量价值呢？
第二个是可度量性
在一个相对复杂的问题上引导实施一个结构化的解决方案
这个方案的参与者是一群人，所以架构师的产出不完全靠自己，而是靠撬动一群人来完成架构目标
1. 确保最终架构方案的可行性。
2. 确保参与方达成一个合理的实施路径，最终能够完成实施。
3. 确保设计方案可以最大化解决方案的结构性。
在这种情况下，一个架构师想要创造长期的商业价值，就必须同时满足三个条件：
已经有现成的方案，但比较复杂；
参与团队众多，但各个团队的优先级不一样；
公司压力大，能够投入到现存方案的人力资源有限。
这就意味着你作为一个架构师，需要在资源有限的条件下做取舍。
这三个条件很难被同时满足，架构师之所以参与一个方案，往往有这么几个原因：
假设你们已经有一套在一些核心系统上使用的老网关，之后又开发了新系统，却发现老网关落后，于是就把老网关迁移到了 Spring Cloud Gateway 上去。
但是最近你们发现，出于公司整体安全的要求，还需要在网关层上开发安全功能
1. 一种是在现有的两种网关上各自加安全功能；
2. 一种是迁移和整合现有的网关，然后再加安全功能；
3.一种是在这两个网关之外再加一层安全网关，之后再想办法把现有的网关能力都迁移上去。
三种解决方案
在不同的交付时间、需求压力、现有系统复杂度和研发人员能力的组合之下， 这三种方案都可能是最好的方案
作为架构师，就要在兼顾方案可行性和实施路径合理性的同时，寻找一个最合理的结构化方案。
所谓最合理的结构，就是从长期看，网关层不是越来越复杂，而是全公司统一、易维护和高可用
如果相关方都能接受长期规划，那么构建第三个网关，然后逐渐把现有网关的功能都迁移上去，可能就是最结构的方案
反之，如果你的迁移项目烂尾了，那么两个网关变成三个网关，而且在迁移到一半的情况下，安全和网关逻辑散落在各处
那就是一个糟糕透顶的设计。
设想
架构师需要做的
所以架构师在这个过程中创造的增量价值就在于能够审时度势
在企业内部各种资源限制和现实条件下，找到合理可行，并且能够最大化企业长期价值的架构方案。
架构师如何创造自己的增量价值？
两个关键元素
具体怎么做
做架构和做业务一样，都不能靠饱和攻击取胜
而是靠对阶段性精确目标的最大化投入来取得进步。
保障架构活动的长期商业价值
在架构规划中寻找扩大收入的机会；
在架构规划中寻找减少成本的机会。
五个部分
07｜法则三：架构师如何找到自己的商业模式？
如何为你的公司、部门或团队提供可量化的增量价值呢
如何寻找扩大收入的机会？
指的是从个性需求中抽象出共性的机会
也就是从解决一个具体问题的过程中得到启发，并从中找到一个可以规模化应用的机会。
比如做用户调研时，你发现有一个用户总是截图之后再通过微信把商品发给另一个人
那么你就会意识到，可以开发一个分享工具，通过小程序和 DeepLink 来获得更多的社交裂变
看到了别人忽略的小痛点，或者在别人不去排查的小异常上执着探索，才最终跨越了现实的障碍
在别人容易忽视的痛点和异常点上，深度挖掘可能大规模复制的机会，不失为扩大收入的好方法
在小数据里看大机会
靠数据来打磨用户体验
也就是通过数据分析找到机会点，然后通过产品和技术的改进，不断提升转化减少损失
这是算法和数字化运营的常见办法。
比如淘宝 App的首页跳出率是 2%，就是通过数据分析和打磨而不断提升的。
在大数据里看小机会
在小数据里看大机会，在大数据里看小机会
方法
扩大收入
人力成本
时间成本
机会成本
包括技术的迁移成本
但在一个企业中，追求完美必须以成本可控为前提。
减少成本
刚去 AliExpress 时，负责公司的全站架构
那时全站的性能非常差，但大家不知道这个差到底意味着什么，也不知道做性能优化到底要付出多大成本，又能带来多大回报
也就是说，我们有办法获取任意一个页面上跳出率和加载时长的关系
有办法获取任意一个页面上流量分布和加载时长之间的关系。我们也知道如果针对一个页面做优化
当时我们已经有了全站的埋点
比如 JavaScript 优化、内容的静态化、图片压缩、动态加载等，都可以用来提升页面性能。
但问题就在于，如果针对每个页面的优化都要做投入
再加上维持这些优化效果，就要对页面的变更做限制和性能监控，那么付出的成本会非常高昂
能够准确度量性能优化后每个页面的预期产出。
优化思路
案例背景和分析
第一，你作为一个架构师，在架构设计中要追求商业价值。
第二，想要创造商业价值，就必须不断度量你创造的增量价值，这样才能确保自己处在价值创造的前沿。并且能够在一个相对未知的环境下，不断寻找自己的增值空间。
确保最终方案的可行性；
寻找最优的实施路径，确保最终能够完成实施；
试图最大化最终解决方案的结构性，以最小成本放大你的产出。
第三，作为一个架构师，要最小化整个架构活动的成本。你要做的是：
第四，做架构和做业务一样，都不能靠饱和攻击取胜，而要靠对阶段性精确目标的最大化投入来取得进步。
第五，不断寻找通过技术手段扩大收入的机会。
第六，不断寻找通过技术手段缩减成本。
我是如何践行生存法则的？
性能优化案例串讲
在日常的架构工作中，就要从创造商业价值出发，理解自己所在团队或企业的商业模式
理解自己为企业创造的增量价值。然后通过技术手段，最大化自己或团队的商业价值创造。
前者需要你不断探索、度量你的增量价值。
后者则需要你关注成本，平时能省则省，看准了机会之后再对精确目标做最大化投入，以取得最大的回报
那就是寻找扩大收入和减少成本的机会这两种。
08｜法则三：架构师如何在一定时间内最大化自己的增量价值？
在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。
在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。
这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术
为什么有的人能够看准一个技术的生命周期， 而有些人却做不到
找到了根因，也就知道自己该怎么改变了。
你有没有见过有的人年复一年辛苦劳作，却一无所成。
而有些人似乎没怎么使劲儿，却能飞黄腾达。似乎大风总是吹向这个猪
你嫉妒地牙痒痒，心想，难道风就不能停下来，摔死这头猪？
现象
自我麻痹是指我们用各种方法让自己放弃思考和探索的欲望。
出现这种现象的根源，就在于高层管理者和软件架构师。
有的管理者有意无意地把工作繁忙等同于有产出，于是让团队持续做毫无目标的布朗运动
只有承认和面对现在的风险，才有勇气放弃麻痹自己的行为
把部分注意力从当前技术放到更新、更有颠覆性的技术上去
而不是被动地等着他人告知自己下一步需求。
1. 自我麻痹
心理安全感的需求导致我们会畏惧改变，这是我们与生俱来的本性。
其实我们都一样，一旦赌注足够大，就会产生畏惧
我们率先放弃了改变的勇气，跟着就会放弃改变的欲望
得过且过，离新的技术趋势越来越远。
2. 畏惧变化，以最小化改变来维持自己的心理安全感；
如果我们被某个史诗级的训练样本冲击过，都会过度相信自己过去成功或失败的经验
这会让我们看不到其他的技术可能，更别说新的技术趋势了。
3. 路径依赖，以过去的成功经历来应对未来案例。
让我们放弃思考的三大弱点
在这两个时间点，我会放下当前所有事情，有没有获得什么本质上的能力提升。
没有提升的话，我会很沮丧。不过我心比较大，过两天就又恢复正常了。
但是半年后，如果发现自己还是同样沮丧，那么我就会琢磨，是不是要逼迫自己找个更有压力、更能成长的事情和环境了
首先，日常工作中我也经常会麻痹自己。每年会留出两次深度忏悔的时间。
我会用对获取惊喜的期待，来压制内心的恐惧
克服内心的恐惧，迎接变化
我记性还不错，表达能力也比较强，而且我也经历过很多波折。
但到了后来带团队时，就发现这些特性看起来是优点，其实会放大我的路径依赖。
开始刻意让自己更关注那些想法独特，或者是经常挑战我观点的人
比如下属反对我的话，如果我们各自的逻辑都很严谨，仅仅是假设有所不同。
那么我表达观点之后，就会强迫我放弃自己的立场。
一来可以防止我有路径依赖，
二来也是为了培养下属，让他们有足够的决策空间和犯错空间
好处
路径依赖最难破。
如何克服人性的弱点？
横轴是时间
竖轴是流行热度
指的是技术被公开，媒体热度陡然上升，还没有成型的产品和商业应用场景。
1.萌芽期 （Technology Trigger)
指的是有了一些成功案例，当然也有失败案例，技术被吹捧到了极致。
2.至捧期 （Peak of Inflated Expectations)
这个时候，热度回归到理性，失败案例被放大。
如果产品不能让早期受众满意，那么技术就会在这个阶段消亡。
3.低谷期（Trough of Disillusionment）
产品逐渐找准在行业的价值定位，二代三代产品出现，产品逐渐出现理智的商业用户和成功案例。
4.灵感期（Slope of Enlightment）
在这个阶段产品被主流市场认可和采用。
5.产出期（Plateau of Productivity）：
以该技术为基础的产品，已经逐渐开始被下一代的新技术所替代，产品的市场范围和利润逐渐被蚕食。
1.衰老期（Progressive Aging）：
产品已经完全退出主流市场，仅仅在一些场景契合度与替换成本都非常高的情况下，还在被维护和使用。
2.退出期（Fade Out）：
产出期还有两个阶段
五个阶段
热度曲线
所有的技术都像人类的生命一样，也有终结的一天。这是个自然规律。
一个老去的技术就让他老去，快死的架构不值得投入人力和时间去维护，更不用说去翻修或者是复用了。
曾经再伟大的技术，在用户的面前都是渺小的。为了更好的用户体验，一切都值得推倒重来。
如何通过热度曲线看技术生命周期？
如何克服弱点去把握技术趋势？
把握时机
09｜法则四：为什么要顺应技术的生命周期？
技术真正的推动力来自市场，需求规模决定技术走向。
这由经济规律决定，不以个人意志为转移
哪怕一个头部大厂，也不能完全决定技术的未来，而是市场规模和成本结构决定技术发展的走势。
技术未来的趋势，谁主沉浮？
看技术趋势，甚至看任何发展趋势，都要先找前置量（Leading indicator）
思路
对于软件发展而言，硬件的革新往往是前置量。
首先，硬件技术进化的驱动力是需求规模。
其次，硬件技术的进化来自驱动用户侧的体验变革，再传递到软件的变革。
计算设备的出货量决定软件架构
如果你知道摩尔定律和出货量为王的规则，你会决定怎么决定架构呢？
在架构设计上，要尽量寻找利用和放大规模效应机会
保障开发软件所带来的价值在规模增长的过程中不断变大。
从硬件技术发展看软件架构的未来
软件行业内的竞争，则是软件架构技术发展的第二个核心推动力。
我们要把架构依赖在你认为的那个赢家身上。
第二个核心推动力
从“天神打架”看技术趋势
技术的真正推动力来自于市场，而市场的一个重要变革因素就是商业模式。
所以商业模式也决定技术的最终走向，是个前置量。
盒马在高端社区的模式证明这是可行的。线下拉客，线上复购
缺点是在铺开过程中找不到足够多的高端社区
而且建店时间周期长，专业人才招聘困难，扩张速度慢
缺点
盒马线上线下模式
叮咚买菜的成本结构远远优于盒马
一是没有门店，不需要像盒马一样找专业的管理与运营人才
二是前置仓面积小，所以铺开容易，扩张速度快，成本也低。
优点
但生鲜的季节性挑战依然存在，所以叮咚买菜在扩展品类到冷藏冷冻食品上下了很多功夫。
难点
叮咚买菜的前置仓的模式
因为它把履约成本和前置仓也降低了，让团长来负责团点，用户自提。
拉新成本也因为团长的存在而变得更低，所以一下子有大量玩家进场争夺市场份额。
相比前置仓，这个模式的履约成本更低
社区团购这种商业模式单均成本更低、扩张更简单、对管理人才需求更低、规模效应更大，也就是说社区模式的确更先进了
所以这个模式扩散速度就非常快，对相关技术人员的需求也非常大。
社区团购模式
当新的模式出现后，你要提前看到这些商业模式各自的优劣势
尤其要从成本、规模效应、增速、技术增值空间等视角来看。
当你发现了一个有优势的商业模式，就要立即去关注、思考和尝试做相关的技术创新。
从商业模式看技术未来
可以运用这些规律去选择我们的职业，选择我们的架构
把自己和团队的未来赌在哪个方向上，决定了我们在某个商业模式上要投入多少时间去学习和研究
以作为普通架构师，研究技术趋势有一个显而易见的好处，就是帮你选择一个正确的行业，正所谓“男（女）怕入错行”嘛！
作用
要更早地从硬件发展、软件技术竞争格局和商业模式进化的角度，去看未来的技术趋势和架构机会
当你评审别人的架构选型时，一定要关注他是否采用了一个已经有规模优势，或者是即将具有规模优势的技术
任何一个新技术，你进入的时间就决定了你的未来
萌芽期赌命
增长期圈钱
至捧期交学费
灵感期拿价值
产出期养老
衰老期做死
退出期刨腹
技术的不同生命期选择
在这个赌命的过程中，你不但可以学习设计思路，看到一个技术的成长与发展过程，而你自己也能获得先发优势
如果精力允许，那么多看些萌芽期的技术，对于你的成长而言会非常有价值
投入到一个萌芽期的技术的确意味着更大的风险。
当你听到某个大词已经满世界流行，到处有人写书开课时，其实它已经过了至捧期。晚了！
对于个人而言，技术的初期充满风险，但值得进入。
规律
看清楚技术发展周期之后
10｜法则四：架构设计中怎么判断和利用技术趋势？
前四条法则分别讲了目标、资源、人性和技术周期，这些都与架构活动的外部环境有关
今天我们来讲讲在架构活动内部，也就是在架构师可控的范围内，应该遵守哪些法则
外部适应性是指一个企业对外部环境变化的适应能力，以及对新机会的捕捉能力。
我特别要强调“外部”这个词。它表示适应性不是面向企业内部的，而是企业在外部环境发生变化时、在与其他企业竞争时所具备的适应能力
在企业中，不同职能所处的视角不同
那么你作为架构师，需要从自己的视角为企业注入外部适应性
同时在这个过程中，提升自己独立创造价值的能力。
通过商业和投资手段，来迅速捕捉外部的商业机会
从而为客户创造价值，为企业获取竞争优势
比如大公司通过兼并小公司进入一个新兴市场。
业务同学
通过新场景迭代效率，来提升企业的市场竞争力和市场占有率
比如阿里的大促运营，就是通过一系列营销手段来提升获客效率和销售额的
从而扩大了市场渗透率。
运营同学
通过不断打磨产品来提升用户体验，从而达到提升企业竞争力和市场占有率的目标
比如抖音创作者和用户端的产品优化。
产品经理
通过打磨技术体系来支持产品和运营，从而达到提升企业外部竞争力的目标。
比如各个互联网公司都在打磨个性化算法、运营后台、数字化运营体系。
架构师是技术职能的一种，所以也是通过打磨技术体系来为企业注入外部适应性的
架构师仅仅可以通过组织架构活动与优化架构方案设计，来为企业注入外部适应性。
架构师
具有人员管理的职责，因而可以通过人才招聘、培养和组织架构的调整来创造价值。
研发经理
可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性
研发人员
技术同学
在大公司某个程序员晋升时经常会套用这样一个逻辑：“我们的大促业绩同比增长了 50%，所以我应该晋升“
仔细想想，这个增长到底是业务方在大促期间多拓展了一倍商家带来的？
还是产品同学重新设计了大促的商品圈选和反向招商逻辑，导致平台商品增长了 30% 带来的？
还是你通过技术创新，用知识图谱把商品之间的语义标签做得更多更准，导致交叉售卖的量增长带来的？
我们把这一组研发人员称为业务线研发
在一些公司里，这些人一般直接向业务部门汇报
比较常见的是增长的产品和技术人员同时汇报给增长业务部门，以迅速响应新的业务机会。
第一个层次，研发活动由业务驱动，直接在业务人员的指挥下响应外部机会
产品把业务活动抽象为一组产品，沉淀出产品矩阵，并通过产品运营不断打磨用户心智
在这个过程中，相应的技术人员会不断提升自己对产品的理解，并通过技术手段放大产品提供给用户的增值
比较常见的产品有营销产品、供应链产品、物流产品等。
除了产品特性本身外，一些纯技术手段
比如营销的资金池优化、反作弊、供应链优化、物流调拨等等，也会为产品带来新的增值手段。
第二个层次，研发活动由产品规划驱动
架构师和研发同学对业务、产品做了一系列的抽象，最终形成由技术驱动的技术产品。
比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎，都属于这一类产品。
第三个层次，研发活动就是由架构师主导的架构活动
分别代表研发活动的三个不同层次。
假设你所在的企业有比较复杂的物流场景，那么业务团队经常会找新的物流供应商
为平台提供物流的外包服务，或者是覆盖一个新场景，也或者是覆盖一个新路线
那么相应的业务线物流团队，就需要与供应商对接，迅速完成接入
业务驱动
但是随着时间的推进，团队在物流上的经验变得更丰富了，物流线路也越来越多，单个供应商对接的方式只会越来越低效。
这个时候，就需要有一个产品团队，把企业内部与物流相关的服务抽象成一组产品，让产品替代人力完成供应商的接入需求
产品和技术同学可能抽象了一组物流的自动接入 API，定义了要交换的数据和相应的交换标准，甚至提供了沙箱环境，为第三方软件服务提供商提供便利
他们甚至可以介入，帮助物流供应商迅速接入。
产品驱动
随着产品和技术能力的进一步提升，技术同学可能会看到更多机会。
比如对不同物流提供商的履约能力、履约时效、服务质量、用户满意度等做评分，形成一个供应商的信用系统。
这个信用分可以用来控制履约成本，保障履约质量，以及提升供应商的合作意愿
技术驱动
案例
业务、产品和技术视角的差异性。
架构师需要在技术层面为整个企业的技术体系注入外部适应性
这才是你独立于其他职能所创造的长期价值，是你有底气的自尊的源泉。
不同职能之间视角的差异性
架构师怎么做才能为企业的技术体系注入最大的外部适应性呢？
就必须理解削弱一个技术体系外部适应性的因素都有哪些
比如业务和产品同学，几乎不关注技术体系的外部适应性
一来他们不擅长
二来这也不是他们工作的优先级
技术之外的同学
往往也很少关注技术体系的外部适应性
技术同学经常受到来自业务和产品同学交付时间的压力
这样一来，技术质量都很难保障，更不用说技术的外部适应性了。
第一，业务交付时间的压力。
最近几年技术岗的供给比较缺乏，很多技术同学频繁跳槽
在一家企业的工作时间较短，因而他们在客观上就不太关注自己的技术口碑。
第二，技术岗的供给压力。
不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定
而需要长期打磨的技术能力，既不能被关注和度量，也没有资源被孵化
结果就是短期效应非常明显，自然，技术同学就很少关注技术的长期适应性了
第三，考核的压力。
业务线的技术同学，以及与产品密切配合的技术同学
企业内部压力的影响
比如多个企业对流量渠道的竞争，大促和营销力度和时长，履约和服务的人群和地区性优势，等等
有的影响是业务层面的。
比如不同的用户体验和用户心智，不同的产品定位和功能，等等。
有的影响是产品层面的。
比如对长尾设备的覆盖，对创新技术的支持，商业生态、产品技术和 API 的开放性和兼容性，等等。
也有的影响是技术层面的。
最常见的削弱一个技术体系外部适应性的外在因素就是竞争
企业外部环境的影响
不论是业务线研发、产品研发，还是基层技术的研发
这些同学的本能反应，都是先维持自己的生存空间。
因为各个领域的内部目标、具体挑战和资源环境都不相同，所以每个领域的研发人员设计出来的软件架构自然也存在差异
研发人员由于自身认知局限、沟通的局限，或者是为了保护自己团队的利益，导致他们的设计都是局部最优，而不是全局最优
这种局部和全局的冲突，在一个跨团队的大型架构活动中很容易外化出来，导致整体的外部适应性随着组织复杂度的提升而被削弱。
企业组织结构的影响
影响技术体系外部适应性的因素有哪些？
架构师能注入外部适应性？
11｜法则五：架构师为什么要关注技术体系的外部适应性？
据目标做出正确的取舍。为什么要做取舍呢？
根据我的经验，绝大多数的业务和产品需求只是一个小尝试，而并非战略性投入
对于这类业务尝试，响应的速度是第一优先级，只要不破坏外部适应性即可。
技术人员如何在高速响应业务和技术需求的同时，还能够保障技术体系的外部适应性？
如果你有比较深度的业务理解，其实不难对业务尝试和战略投入做出区分，你甚至可以判断一个需求的商业价值和成功概率究竟有多大。
你也可以与高层不断沟通。确认自己对业务尝试和战略投入的判断
对于业务尝试，我们需要以最低成本完成这么一任务：从这个尝试中得出一个正确的结论
这种情况下你要做的就是在保障尝试结论有效性的前提下，最小化这个尝试对系统的冲击，因为大多数尝试是不成功的。
意思是说，如果把一个小范围的尝试放到更大的范围内，它的价值依然存在，方法依然有效，那就说明结论是有效的
它与产品的完整性，技术可扩展性、安全性、可维护性等等几乎毫无关系
也就是说大多数时候，你在实现这类需求的时候可以忽略多数横向问题（Cross-cutting concerns)， 把开发成本降低到极致
比如说你圈选了哪些城市、什么目标人群、花了多少营销预算、在什么季节做投放等等
很多人都在试图挑选有利于拿结果的实验环境来做出结论
哪怕是那些所谓的“成功”的尝试，其实结论有效性也要打个折扣的
结论有效性与实验环境有非常大的关系
影响因素
结论有效性
指的是要把每个业务尝试尽量封装到一个单一模块中
好处是一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
第一，单一职责
指的是整体架构设计要保障大多数业务尝试可以在业务层完成
如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨团队合作，这种架构会大幅降低业务尝试的速度。
第二，最小依赖
一个正在尝试中的业务应该尽量减少与其他业务模块的数据交换，尤其是输出，这样才能最小化它的爆炸半径
否则该业务尝试的数据模型会污染到其他业务，在尝试失败之后对其他业务的影响也会很难剥离
第三，最小数据共享
指的是在业务尝试期接口不对部门或企业外部暴露，包括 API、数据共享、事件、消息流等一切对外界造成影响的通讯机制。
第四，最小暴露
遵循的原则
所谓足够长，对于阿里腾讯这样的大厂来说，至少三年起
如果你的部门体量小，那至少也要一年起
这哥们分不太清楚业务尝试和企业战略，他的需求我还是要封装好。
所以如果你的业务方每月给你一个新战略，那你可以非常确定地告诉自己
战略级项目应该在全公司层面明示，而且要维持足够长的时间。
你的目标不是保障这次变更的最小爆炸半径，而是让战略转型做得尽量彻底
甩掉尽可能多的老包袱，使得未来的企业变得更灵活（至于如何做好战略级项目的架构规划，我们会在模块二详细描述）。
的碰到了三年一遇的战略转型
战略级项目的判断原则
业务交付时间的压力
当然我们还提到技术岗供给压力导致技术人员的稳定性差和设计短视的问题。
我们都要有有效地封装业务尝试的能力， 这个能力最终会转化为你提升技术的外部适应性的能力
这是一个技术人员的基本功，从你写代码的第一天就需要。
只不过随着你的职业发展，你从封装代码逻辑，到了封装业务逻辑，最后到了封装业务尝试
第一，提升对封装能力重要性的认知
在这里，设计评审很关键。业务尝试也要有设计评审，而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
第二，建设复杂度控制机制
在公司范围内推行奥卡姆剃刀（Occam’s Razor）原则[1]。
任何增加功能、引入复杂性的设计，都要做一个正式的评审，而简化的行为则不需要。
第三，推行最小必要架构原则
技术岗供给压力导致技术人员的稳定性差
比较好的办法是把绩效考核仅仅与业务结果绑定
把技术线晋升与长期的技术体系建设绑定。
完善技术体系的考核
设计短视的问题和考核带来的短期效应
三个挑战
如何抵抗内部压力而为企业注入外部适应性？
什么是真正的业务理解
在一个互联网企业，特别是小公司，业务、产品和技术同学需要一起 **** 去认识行业、市场和竞争等外部环境
这意味着每个职能的认知是同步的，是平行迭代的，是没有偏差的。
要从技术视角去理解业务，并将自己对业务的认知转化成一个技术动作
而这个技术动作，最终会和业务动作、产品动作一起，将企业带到一个更好的生存位置上
这才是真正的业务理解，也是你独立于其他职能所创造的长期价值。
你通过了解外部环境而获得的第一手的业务认知，而不是你从业务、产品同学那里获得的二手、三手的认知
从某种程度上来说，这是多个职能在做分布式的学习
在这个过程中，你只是一个技术锤子，在用技术视角去理解业务这个钉子
你不仅要看懂业务人员做业务、产品人员做产品。还要看出门道，最好能提出建议，以及最终预测出的结果。这才是你的业务理解。
技术人员
一个架构师要拥有的业务理解的能力，是基于自己对业务深度认知之后的技术洞察
然后通过这个技术洞察来推动业务发展的能力。
拥有了这个技术洞察后，你甚至能从业务视角上看到业务机会，或者从产品视角上看到产品机会
再进一步，你的技术洞察才能为业务和产品赋能
最终，三个职能合力推动企业的发展，而不是三个职能单打独斗。这也是图中红线的真正含义
技术洞察之后
对架构师而言是架构抽象和架构设计
对数据工程师而言是数据建模和数据资产建设
对算法工程师而言是建模和算法调优
这些技术动作最终都会作用到业务层面上，从而创造出增长和新的业务机会。
不同的视角和动作不止一种
如图所示
我们用上节课里提到的物流的例子，来具化一下技术动作
假设你通过架构抽象定义了物流服务供应商这样的概念，那么你对供应商的能力就可以做进一步的抽象和量化
指某供应商对每个类型的服务所能提供的最大服务容量
这是一组与业务场景有关的度量，比如说多个小件包裹 / 天，多少次登门安装 / 天等等。
1.容量
指该供应商的服务价格随着服务容量变化的关系。
2.价格曲线
指该供应商的服务质量随着服务容量变化的关系。
2.质量曲线
指与该供应商维持商务关系所要保留最小服务的容量。
4.最小容量
比如你抽象出了四个维度
有了这些维度的度量和建模，你就可以设计一个调度引擎，使其在多个供应商之间做调拨，同时最大化服务质量、最小化成本。
你可以不断量化和监控服务商的真实服务容量、服务质量曲线，同时对价格和质量曲线的预测做出调整
而业务方呢，也可以通过这组监控和对业务未来走势的预测，决定是否要对现有供应商组合做出调整。
而有了这个调拨能力，业务的运营也会发生变化
比如说通过最低容量保障去刺激某个供应商扩大自己的服务容量，或者是提升他们的服务质量承诺
业务方甚至可以决定把某些质量监控直接返回给供应商，使得供应商能够主动响应质量分的反馈。
一旦有了这些数字，业务方就可以有新的运营方法
也就是说，当业务方用一组规则驱动一个运营商做出容量或质量改变的时候
这个供应商响应这些规则的能力和时间延迟也可以被度量出来
这些度量就可以转化成一个数字化的可运营度指标， 未来可以用来筛选有潜力的运营商。
而这种数字化的运营方式，就是技术推动业务发展的一个案例。
更进一步地，业务方可以开始度量和管理一个供应商的可运营度
流程
案例指引
业务理解
在一个充分竞争的行业，大多数企业并不具备对外部适应性做长期规划的条件。针对这种情况，架构师该如何应对呢？
站在业务、运营、产品和技术的视角，不断监控和思考竞争对手
然后用技术手段做出应对方案。
深度理解竞争环境
最后一类挑战就是研发人员的人性与企业的组织结构
而企业组织如何影响外部适应性这个话题，其实与企业的文化环境有关。这个话题，我们会在接下来的法则六中深入探讨。
认知和组织冲突
12｜法则五：如何提升一个架构设计的外部适应性？
出现各种有争议的问题之后，争议各方最终是怎么做决策的呢
比如确定架构选型、架构设计、交付等等。
1.决策方式
团队上下级是怎么沟通的?
在制定架构方案之前，你有办法获取到企业的真实目标吗？
你能把这个目标传递给架构活动的其他参与者吗？
2.沟通方式
任务执行过程中是怎么样呢？
是你作为一个架构师和研发人员一起不断的主动提升认知寻找最优的实现方案？
还是说所有执行者都是以交付需求为目的，不论对错只要按时完成就可以了？
3.执行方式
三个维度架构活动
架构师需要什么样的企业文化环境？
先从一个假设开始
再根据实验和观察得到一个客观的结论
最后这个结论如果是正向的，说明你的设计非常有效，也创造了价值
如果结论是负向的，说明你要发现问题，修改设计，再提出新的假设与设计。
科学的探索
1.你从上节课里提到的技术洞察里产生一个商业假设，也就是你的期望你的技术能带来的商业价值
2.之后你通过架构设计最大化你创造的价值
3.如果项目上线后你成功了， 那你预期的商业价值就实现了
4.反之你发现问题，重新修正你的假设和设计。
这是一个不断假设、求证、再假设的过程
架构师的做事方式和科学的探索差不多
这种文化主要是在思想和认知层面，属于知行合一中“知”的部分。
企业的文化环境必须要足够包容和求真。
第一层，企业对探索过程的包容，尤其是对失败的包容。
架构方案的最终质量，取决于你与所在组织能够吸纳多少不同的意见
愿意接受不同观点，并对不完美方案做出修正的人，就越容易获取更高质量的观点和建议，做出更好的决策来
第二层，企业对不同观点的包容
Inclusive，这个词没有一个准确的英文翻译
这个词其实说整个企业和你自己都不排外，要带着大家一起玩的意思
不是一层一层越来越小的圈子，而是一个开放的社群。这是你架构师获取高质量观点的前提。
第三层，企业对人的包容
包容有几层逐渐递进的含义
我认为这和科学探索一样，最终能够持续逼近商业规律的真理的人，必然对真理有一种发自内心的执着
这种求真的性格和工作方式，有利于帮助整个架构活动产出更逼近真理的架构方案。
第一层，你和你的合作伙伴们的求真的信念
这个真理简单来说就是一个企业可以长期利用的商业规律。
但是更深层次上， 是一个企业追逐的真实目标是什么？ 到底什么对企业最重要？是赚到更多的钱？还是占有用户更多的时间？还是商家和店铺在你这里得到最大限度的成长？
这就是法则一里面提到的正确目标的概念
其实这些问题的最终本质就是大家常听到的使命、愿景和价值观。
第二层，企业内部的所有决策者们对企业想要逼近的那个“真理”有共识
我们要看企业挂在嘴上的使命、愿景和价值观，企业内部从业务到产品到技术是不是真的在践行。
毕竟，在知道与做到之间，横垮着一条不可逾越的鸿沟。
第三层，一个企业在求真上的知行合一
求真也有三层含义。
什么样的文化环境对架构师是友善的？
听其言不够，更重要的观其行。
比较容易的办法，就是在公司内部观察
所谓对称，就是指企业用来约束员工行为方式的规则，是否适用于所有员工。
换句话说，是否存在特权阶层可以随意解释、更改和超越行为约束的规则呢？如果存在，企业的规则就不具备对称性
也就是说企业不是靠法制的。那么员工就不会把企业宣扬的法，也就是文化，当回事儿
而包容的文化，有利于在有不同观点和背景的人群之间建立起更高质量的信任，可以是对称的。
第一，看行为方式的对称性。
比如一个企业鼓励员工不唯上，要有勇气反对领导的错误决策。
但真正有勇气站出来反对的人，他们的命运如何呢？是被晋升还是被打压了？
反之，那些唯上的人呢？他们是被晋升还是被打压了？你只有从反馈机制看企业要什么、不要什么，才能获得更真实的信息。
如果反馈机制与企业宣扬的文化背道而驰，就说明是反馈机制决定了企业文化。
第二，看最终的反馈机制。
企业可以快速发展变化，但企业文化却要保障其内在连续性
因为文化约束力需要长时间的养成。如果文化不断被调整，证明这个企业的文化在生成过程中的决策机制，大概率是存在问题的
此外，文化的形成时间越短，就越难以被多数人认同。没有认同，那么文化对行为的约束就会失去效力
换言之，频繁变化的文化，不太会在企业内部产生足够的约束力。
而真正产生约束力的，一般会是其他利益分配机制或惩罚制度。
第三，看企业文化的连续性。
鉴定企业是否真正做到了“知行合一”的三种方式
如果企业的文化连续时间长、约束规则对称，而且真实反馈也与宣扬的一致，那么这个企业的文化就是知行合一的
反之，就证明这个企业没有可以让架构师借力的文化环境。
如何识别企业的真实文化环境？
通过你的行为（Leadership by Example）来影响和打造。
你的行为方式往往会影响身边人，甚至是参与架构活动的人。
经常把架构师称为技术领导者，领导者有一个重要的能力，那就是影响力。
不是通过职位，也不是通过权益的分配，而是通过你的行为来改变周围人的行为。
比如说你把企业的稳定性体系迁移到 Service Mesh 的决策就没办法同时让整个企业和你自己团队的利益都最大化，但是你选择了前者
你是在代替许多人甚至是整个企业做决策
别人把他的领域的决策权交给了你，所以你其实预支了他给你的信任，从而获得了做决策的机会。
这份信任和机会，是靠你的良知换取的。
架构师的特殊性
作为一个架构师，有良知是个必要条件，而不是一个选择
良知，有利于你与架构活动参与者建立信任，最终推动整个架构活动走向成功。
架构师有良知是个必要条件，却不是对其他架构活动参与者的要求，也不是你日常生活的要求。
从上帝视角来看，自私是人的本性
只是我们架构师在行使决策权时，其实已经进入了一个事先拟定好的条约里。
在这个条约之下，我们的决策必须是由良知驱动的，从整体利益出发，而不应该有任何自私的一面。
架构师最重要的品质-良知
我认为勇气也是架构师这个职能的必须选择
比如架构方案被完全扭曲
架构师是一个组织里全局视角和长期视角的唯一代言人，沉默就可能造成严重后果
你的勇气可以帮助所有架构活动参与者认识到企业的全局利益和长期规划
最终帮助大家找到最利于整个企业长期生存的架构方案。
一个人的判断力大幅提升就是要靠你在巨大压力之下做出不同与其他人的但是是最终正确的决定
这个判断力提升过程我认为只能靠你的勇气来换取。
架构师最重要的品质-勇气
架构师如何在小范围内打造一个友善的文化环境？
你自己可以推演一下，在一个准入门槛相对低且高度竞争的行业下得以生存的企业应该是帮派文化的
这是它所在的行业和它自己的发展历史决定的
这个企业文化不是为了最大化架构探索的成功率而设计的
也就是说除非你自己创业，如果说你加入到了一个成型的大企业里，是什么文化就是什么文化。
如果你以包容和求真的方式做事情，你的行为是否可行？
如果你有良知和勇气，你是否最终能够引导公司走向一个正确的架构方案？
在某些企业里面，这两个问题的答案的确是“否”，甚至不是“难说”。
因为企业文化一旦形成就非常难改变，一个架构师是很难凭借一己之力改变整个企业的文化的。
在企业里，你只有在一个相对安全的环境才能做有效的架构探索，找到真正能够为企业生存带来长期优势的架构方案。
如果你整天忙着在各个门派之间做和事佬，那训练的不是你的架构能力，而是你的外交能力。
也就是你所处的环境不但是不友善的，甚至是有害的，那你该怎么办呢？
架构师的黄金年龄很短，良禽择木而栖。
哪怕你拿着不低的收入，那我也建议你考虑离开，因为你在不断丧失可以提升你架构能力的机会。
你所在的企业是否有好的文化环境能够让你作为一个架构师顺利的完成一个架构活动？
思考
对文化环境的选择
13｜法则六：如何鉴别文化环境是否有利于架构师的生存？
就是采用相信过程正义的工作方式，用一组原则来指导行为和决策，而不是随心所欲地工作。
如果放在架构活动的情境中，就表示你作出决策的每一步都是公平（Fair）、正义（Justified）和可解释的（Explainable）
而不是靠一两个人的强势来达成的。
过程正义
架构师可以和架构活动参与者一起找到那个更优的路径。
过程正义的价值
这些指导原则，可以是参与者为这个架构活动临时约定的
也可以是我们讲的这六条生存法则
架构活动参与者都要在事先约定的某几个原则之下，来进行决策和行动
这么做，有两个最显而易见的好处。
你是法则的发现者和传播者，但同时你也受法则的约束，这是一组行为信条，引导你与周围人共同去做正确的决策
对于架构师而言，不论你出具什么规则，都没办法全面证明法则是万能的，适用于各种情形用。
那么在无法证明的情况下，对称性就要求我们敢于包容不认同法则的人，而不是打压他们
所以我一直认为那些举起道德大旗想一下子把对立者置于死地的人，是不讲公平正义的。
对称性，从某种程度上来说，暗示了某种形式的包容
一方面，法则具有对称性
同样的，你作为架构师，也可以总结你组织架构活动的法则，从而吸引更多有相同“道”的人
另一方面，我们共同坚信的做事的法则就是“道”
架构活动的成功规律都是可以被发现、表达和反复使用的。
我们这六条生存法则选择了一个答案：达尔文主义价值观，即企业生存是第一优先级。
何为成功
道可道：生存法则背后的总体价值观
1.它们适用于我的个人经历，以及我能近距离观察到的场景中（以百计）；
2. 这些法则对我而言，置信度（Confidence Level）足够高（～90%）。；
3. 这些法则能把我的注意引向那些会导致架构失败的关键点上。
4.除了这些根因之外，肯定还有其他根因存在。所以这六条法则具有一定的普适性，可以帮你躲开大多数的失败，但不一定能完全帮助你成功
5.因为这些法则是基于我过去多年的观察和学习，主要是 PC、互联网和移动互联网环境下的观察
为什么选择这六条法则
我现在再把这些法则放在一起
不过这次我建议你细细品味这些法则，从你的注意力、价值创造点和行动点来重新审视这些法则。
对应的法则是要有一个正确的目标
而你的行动点就是确保目标与公司的战略意图相匹配。
第一，审视整个架构活动的方向是否正确
对应的法则是不要搭没有人性的架构
而你的行动点就是在方案设计和架构活动组织中充分考虑研发和用户的人性。
第二，审视参与者动机和用户的需求是否合理
对应的法则是要有自己的商业模式
而你的行动点就是在一个有限资源下最大化商业价值。
第三，审视你的技术是否能够创造商业价值
对应的法则是注重商业和技术的生命周期。
而你的行动点就是选择已经有规模优势或者是即将有规模优势的技术
第四，从技术和商业视角审视架构方案是否合理
对应的法则是追求外部适应性
而你的行动点就是干预架构活动和设计方案来不断地注入外部适应性。
第五，在变化的环境中审视你的行动
对应的法则是构建或寻找一个友善的环境。
而你的行动点就是在思想上要包容和求真，在行为上要有良知和勇气，最终达到知行合一的形态。
第六，审视你是否拥有安全的架构探索的环境
对架构师来说，针对每一个问题，你都需要有一个行动点
法则可以变，但相信法则这个宗旨不能变。
注意
如何做到过程正义
所谓信奉原则
过程正义：为什么要定义生存法则？
第一，多从失败中看机会。
第二，有勇气相信你身边的人。
第三，关于讨论区和思考题。
三个小番外
14｜模块小结：这些生存法则的逻辑是什么？
研发人员的日常工作都是在接需求、写代码、上线、修故障之间循环，很少有时间去思考和追求长远的设计
这种短期行为虽然不影响业务迭代，但如果在一个大型架构活动中出现频繁，造成的后果将是灾难性的
反射式研发交付行为
分布式研发模式往往采用微服务架构
微服务架构有一个优势，就是服务之间可以独立做变更，在保持 API 稳定的情况下，团队之间很少需要协同
所以每个服务的维护者可以独立决定自己的发布流程和交付节奏。
但是在互联网时代，为了最大化流量的传播，我们往往会通过一个大型商业活动来聚合和放大营销效果
比如 618 大促、双十一大促、春节红包、新品线上发布会等等
那么微服务相对独立自主的研发模式，对于制定跨团队统一流程和交付节奏就构成了一个巨大的挑战。
日常微服务的独立交付
大规模活动
康威定律影响架构选择和稳定性
分布式团队
每个团队，甚至每个研发，平时都在自己的隔离环境下高强度地开发代码
所以大家一般没有统一的语言和全局的认知
普遍存在的认知差异
在高风险和高回报预期的场景下，必须保障项目完成的高确定性和对目标的高保真性。
高风险高强度
需要帮助团队抵抗反射式的研发行为、独立决策的研发模式、分散的研发团队、普遍存在的沟通障碍和认知差异
以及高风险、高工作强度和高复杂度的场景，最终保障架构活动以高确定性完成目标。
互联网时代的架构挑战
架构师需要克服现有的分散的研发团队、普遍存在的认知差异、习惯于独立决策的研发团队所带来的认知局限，引导参与者在对架构活动的认知上达成共识。
对目标的共识
对决策方法的共识
对各自责任边界的共识
对资源分配的共识
以及对交付时间
内容和质量的共识等等
共识内容
建设共识
架构师需要克服互联网企业在高度不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱与质量问题
需要在架构活动的全生命周期持续收集、发现、评估、控制和传递风险。
在持续变化的目标和竞争环境中不断提升对风险的理解，逐步完善预案。
并在成本可控的情况下选择合理冒险，同时随时跟踪由外部环境和事件引起的风险变化
及时传递重大风险，最终把风险控制在可接受的范围内。
控制风险
架构师不仅需要提前行动，关注用户价值
还要不断提纯目标，保障交付的价值
以及，需要反复分解架构计划，持续去除盲区，提升 API 的鲁棒性
最后，以分领域、分阶段、最小化的交付来保障项目完成。
保障交付
任何一个大型架构活动的背后，都有着巨大的时间成本、机会成本、商业资源和人力资源的投入
沉淀知识
架构师的作用
架构师需要保障整个架构活动有且仅有一个正确的目标
架构师必须要确定最终的目标可达。
可行性分析
统一语义的过程是一个循环往复的识别不同角色、不同场景、不同语境，然后逐渐建模、整合、修正语义的过程
直到所有参与者的需求能够被准确无损地表达、记录和传递，最终通过架构活动实现出来。
统一语义
在架构规划之初，我们要梳理架构活动的用户角色，发掘每个角色的核心诉求，并从活动目标出发确认需求的正确性与合理性
同时，还要在统一语境下建立问题域模型，与执行者一起推导出从问题域到执行域的映射
在这个过程中，许多领域映射的冲突可能会被暴露，这个时候，我们必须及时将冲突上升，然后尽快解决，尽量避免将冲突带到任务边界划分中去。
执行域映射
任务边界划分是真正体现架构师思考力的地方，也是很多棘手问题集中爆发的地方
在这个环节，我们需要依照搭建架构环境的方法，先为团队建立一组任务边界划分的决策信条
接着，再进行用户需求和任务分解，尤其是对任务颗粒度的判断。
最后，我们要确保任务相关的有限资源被提前锁定。
任务边界划分
在这个过程，我们需要把输入转成一个不但可行而且要有约束力的规划。
除了要最小化项目交付风险外，还要确保所有参与者有能力、有意愿履行各自的责任，从而提升交付的确定性。
规划确认
启动，代表着合同正式签约生效
那么在正式签约之前，我们还有机会将之前未暴露的重大风险公之于众
所以在这个环节，我们需要与执行团队完成一次深度握手，为接下来的实施环节提供问题预警和冲突解决的机制
确保执行过程中可能发生的问题能够被及时解决，团队间的冲突能够被及时化解。
有了这些准备，我们才能以高质量的技术内容和充分的信心来开启项目。
这也是最后一个暂停或延后架构活动启动时间的机会。
活动启动
我将提出一种基于最小增量价值单元的交付策略，以保障架构活动的最终产出
这样做的目的是把问题尽早提给市场，让市场给我们指点迷津。
此外，我们还可以根据线上效果的评估和分析，来调整阶段性目标，甚至是整个架构活动的目标
阶段性价值交付
复盘是被最频繁提起但却很少被认真执行的话题。不过在我看来，这是一个架构师成长的关键。
那么在复盘工作中，架构师需要平衡好不同的审查视角和分析维度
通过搭建安全的复盘氛围、充足的前期准备、对复盘过程针对性的控制、对机会点的梳理与把控
以及讨论过程中的深度剖析，从而发现深藏在流程和假设中的问题
并找到有效的行动点，确保之后的架构活动能够吸取之前失败的教训。
对于架构活动而言，复盘的真正目的是为企业未来的架构活动提升成功概率。
生命周期
15｜模块导读：互联网时代架构师都面临哪些新挑战？
日常工作中相对隔离的微服务研发模式；
1. 分布式研发
分散在全球或全国多地的研发团队，以及由此带来的语言、文化和沟通障碍；
2.沟通障碍
，我们必须理解参与者的核心利益诉求，最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
将利益分配与价值创造相匹配
解决办法
首先是利益不同
架构师往往是从整个架构活动的视角出发，但其他参与者只会从各自团队的视角出发
只有充分考虑到局部视角，你才有机会设计出一个包容的架构规划，才有可能让更多的人达成共识。
其次是视角不同
比如因为职能、工作背景和语言文化的不同，也会带来认知上的差异。
跟每个参与者都进行一次深度对谈，并针对对方的疑惑做专门的解答
职能、工作背景不同的解决办法
架构活动的交付时间压力一般都非常大，不足以将语言和文化背景不同的人融合到一起。
由于语言和文化不同也会带来认知上的差异，相对来说比较难解决
最后是其他的内在差异
由于职能、工作背景不同而造成的认知差异，尤其是由于视角局限而带来的认知差异。
3.认知差异
三个与沟通系相关的重要挑战
但如果想真正了解一个人的内心利益诉求，就需要在日常工作中下大量的功夫，建立信任关系
而且场景越复杂，人越多，那么需要投入的成本就越大
所以建设共识这件事，功夫要下在平时，而不是架构活动开始的时候。
建设共识其实是个体力活
一个没有道义的企业会选择错误的人，做错误的事，最终只能被自己的客户所抛弃。
在架构活动的上下文里，指的是有可能带来损失的不确定事件
风险足够大，是指不确定性事件发生的概率和一旦发生之后带来的损失同时都很大
风险
发现和评估风险是个极其耗时间的过程
在互联网企业，不仅每天都有新风险，而且现有的风险还在不断变化
要是把风险评估作为一次性的前置环节，不仅会占用大量宝贵时间，也不能有效控制风险。
架构师要在架构活动中持续预留一部分的带宽，比如 5% 的精力
任何时候都先关注已知的最大风险，然后随着时间的推移，不断对这些风险形成更深刻的认知
而这些更深刻的认知，最终也将转化成一个能够准确量化的风险控制成本和企业的预期损失
成本更低的做法是搭车制
1.逐渐形成量化认知
在架构活动中，如果我们发现了一个风险，也对损失有了一定的预估，并准备好了预案以响应不确定性事件
这个时候，就可以“冒一次有准备之险”。
2.可以冒险
架构师的权责，还没有大到可以代替公司去决定风险政策的地步
所以必须向上及时传递重大风险和冒险行为，而不是直接采取冒险行为
3.但不能不说
具体如何做?有三个关键动作
架构师能够降低大型架构活动的不确定性和复杂度
最小化架构方案，最终保障高质量的交付
这主要是赞助方对目标的不确定而导致的
第一:首先是目标的不确定性
企业往往会同时有多项研发活动，而企业的整体研发资源不足以完成分配给所有研发活动的任务
那么架构师就必须在有限的研发资源池里争抢份额，以保障架构活动的交付。
第二:资源的不确定性
在一个大项目的初期，无论是架构师还是其他参与者，对项目的理解都比较有限
如果把架构活动拆分成多个阶段性的交付点，在线上看反馈
那么我们就可以根据线上数据来看商业或技术环境变化对架构目标、商业效果的影响，而不是凭空猜测。
缩短阶段性交付周期
指的是尽量提升 API 设计对技术选型的鲁棒性，也就是提升接口和模型设计的抽象性
那么在之后的交付阶段，我们就能对次优的技术选型做更正或者升级。
增加技术方案的抽象性
是在缩短阶段性交付周期的同时，增加技术方案的抽象性。
第三，商业与技术环境的不确定性
指用户需求与我们的期望不一致，或者用户需求随着时间发生了较大变化。
除了从人性出发的设计思考外，还可以基于增量价值来交付单元。
通过线上用户的真实行为来判断用户需求是否与之前的调研一致，同时根据预期行为偏差和效果分析，来决定是否需要对用户体验做出调整
第四，用户需求的不确定性
降低不确定性
不确定性是指问题随时间推移，发生了不连续的、不可预测的变化。
复杂性则强调问题或者解决方案，很难用几个简单的维度去描述
复杂性和不确定性看起来是一码事情，其实差异很大：
就是将整个架构活动按照问题域，分解成不同领域的子问题
然后在每个问题域，从粗到细一步步分解成细粒度的执行方案。
第一，从问题域层面分解架构规划和交付方案
结构性，指的是贯穿企业所有软件实现方案的统一模式
反映在设计上，就是结构化设计（Structured Design），意思是不同领域、不同模块的设计是同构的。
如果所有参与方都采用微服务设计、响应式设计或者前端低代码设计
最大的优点就在于未来的改动成本比较低
这种宏观上的结构性，来自架构师与其他参与者在每个领域的决策上对结构性的追求
研发的任务，也从宏观的领域模型切分，到库表切分，再到字段和消息的切分，粒度越来越细
风险也从刚开始相对宏观的大风险，转移到具体设计上的方案层面上，以及细分模块的交付日期上
第二，增加架构设计方案本身的结构性
分割交付模块的理念与小步快跑是类似的
比较常见的办法是分期交付，比如按部门、按领域或者按架构分层进行分期
第三，按照多种方式分割交付模块。
如何控制复杂度
复杂度控制
不论是分期交付，还是通过单一目标约束架构活动的范围，这些都是最小化架构活动的例子
这个最小且必要原则，是提升交付成功率的最重要的方法。
被架构活动影响到的业务体量的占比
这个比例越低越好，最完美的情况是零，也就是架构活动对上层业务完全透明
在交付的过程中，上层业务还可以持续迭代，不受任何影响
有一个非常重要的架构活动的用户体验指标与最小化有关
最小化架构方案
关键的三个动作
架构师有着区别于其他参与者的宏观视角，因而有必要通过有效的知识沉淀来保障架构活动的思考与决策质量
也有必要为企业未来的架构活动提供宝贵经验和方法论
一方面，架构师需要沉淀完整和真实的过程记录
另一方面，还要为企业注入逻辑思考，引导企业走向正确的决策。
通过各种文档工具、设计工具、沟通工具和复盘工具，为架构活动注入理性思考。
只要是足够复杂的项目和工作，就一定要在纸上把完整公式、思考逻辑和决策逻辑写下来，反复推敲
并分享给周围同事，让大家一起帮我找问题。
经验
17｜通用技能（下）：架构师如何保障交付与沉淀知识？
架构活动的第一步，就是为活动搭建一个架构环境
打个比方，架构环境是用来执行一个架构活动的虚拟机
这个虚拟机运行在现实的物理环境之中，包括企业的文化环境、商业环境和技术环境等等。
而架构活动呢，则会在这个虚拟机中执行。所以我们架构师要确保虚拟机上的进程有稳定可靠的运行环境，不受物理环境变化的影响
指的是在企业的商业、技术和文化环境中，架构师为架构活动所搭建的虚拟的工作环境
包括决策环境、激励环境、资源环境、团队构成、物理和虚拟的工作空间等等。
完整定义
什么是架构环境呢
为什么要做环境搭建？
先说使命，使命是一个企业存在的意义。
再来说愿景，愿景是对使命在不远的将来所能达成的目标的一个具象化描述。一
最后是价值观，价值观是我们在多个选项中做权衡的决策依据。
需要准确感知企业环境，主要包括企业的使命、愿景和价值观。它们是决策环境的基础。
哪怕是在行霸道的企业里，我们也要尽量搭建一个行王道的架构环境，来保障架构活动的成功
环境搭建前的准备工作
在多个参与方 / 团队无法达成一致或者产生冲突时，通过投票、把冲突向上升级、决策者拍板等方式，确保参与者能解决冲突，迅速拿到决策。
注意，这里并不是要达成共识，而是拿到一个大家必须遵守的决策。
决策环境
能对参与者产生驱动力的激励，一般是额外的物质和精神上的奖励
比如我们在第 16 讲提到的通过双倍工资的激励，的确会大幅提升参与者的投入度和合作态度，提高活动成功的概率。
激励环境、
企业中留给架构活动所支配的资源非常有限，这是架构活动的主要约束条件。
资源环境
参与架构活动的成员和团队大致构成。我们需要通过这个条件来确定可行性。
团队构成
指物理上的工作空间。比如让所有参与者在同一个办公区内，或者建立一个虚拟的线上社区。
这种空间会促进参与者之间形成深度交流，减少误解，以便及时解决问题或冲突。
物理和虚拟的工作空间等
环境搭建过程中的关键工作
高效的必要条件是决策的正确性
那么怎么才能形成正确决策呢？
是靠机制。我们必须依靠机制，而不是靠单个人的判断来找到正确决策。
需要预先说明的是，哪怕是机制，也不能保证决策的绝对正确性
但是机制的存在，会让我们的决策环境足够安全。这意味着参与者都愿意指出决策的错误之处
随着时间的推移，机制本身也会不断被优化，从而提供更好的决策保障。
问题一
亚马逊的信条（Tenet）机制就是一个非常成功的案例。
所谓信条，就是所有参与决策者都要遵循的法则。
其目的是将决策引向事先达成共识上。
比如 “消费者第一”这个信条，就是要让亚马逊成为全球最以消费者为中心的企业，所以它是信条的第一位
信条
信条的价值在于它们明确描述了决策原则，让其他人可以评判一个决策的优劣
而信条的存在也大幅提升了参与者的安全感。
信条的价值和作用
架构信条对于架构活动的作用
那么什么是有效的机制呢？
问题二
王道：如何搭建一个安全高效的决策环境？
你相信王道，但现世充满了相信霸道的同事，那该怎么办？
获取稀缺资源的方法也很简单，那就是清晰描述架构活动要创造的价值，通过分析投入产出比
来解释为什么这些有限资源的一部分，应该投入到你组织的架构活动中去
任何一个理智的资源管理者，哪怕他是个行霸道的信仰者，也不会拒绝一笔好的生意。
具体做法
你必须克服企业环境的挑战：游说这些稀缺资源的管理者，取得架构活动的最小必须资源
关于霸道：激励环境、资源环境、人员构成、工作空间
有了一组明确的架构信条，以及最小必须的资源，就可以进入到下一个节点了
但是在互联网时代，变化是常态，必须持续监控别人承诺给的资源，确保有效。
环境搭建完成
18｜节点一：架构活动中为什么要做环境搭建？
架构师在目标确认这个节点上，不仅要保障目标的正确性和合理性，还要保障目标的可达性
也就是说，目标确认是以终为始的
比如在一家电商公司，我们到底是要追求 GMV、订单数、DAU、NPS 还是利润呢
虽然这几个目标对于电商企业来说都很重要，但是在企业发展的不同生命周期、细分产品的具体定位和竞争态势之下，当前最关键的目标只能有一个。
首先是目标正确（Correct），指企业在当下应该追求的目标。
既具备足够的挑战性，但是又不会引起大面积的动作变形
具体而言，合理性覆盖架构活动具体的目标值、交付时间和质量期望。
任何架构活动都需要承担一定的风险，而当某个风险实实在在发生的时候，这个目标实现的成本可能会增加（时间、人力、计算等成本）。
但是目标仍旧需要突破风险，直到被实现，而不是被风险击败。
最后是目标的可达性（Achievable），指目标最终可以被实现
三个概念
站在企业决策者的角度去思考目标，从而帮助决策者做出正确取舍
目标的正确性
以执行者的角度去审视目标，从而以乐观的心态给团队设置一个能带来成就感的合适的挑战。
目标的合理性
从赞助者的视角去审视目标，从而以悲观的心态来确保投资在重大风险发生时也能有回报。
目标的可达性
三个概念的出发点
什么是目标确认？
对企业目标的准确感知；
对架构项目核心角色（决策者、赞助者和执行者）的确认；
明确架构活动可以为这些角色创造的核心价值是什么，以及怎么度量这个价值。
在架构活动中有四个核心角色：决策者、赞助者、执行者和用户
不仅这四个角色是为企业愿景服务的，企业中的所有架构活动最终也都服务于企业愿景。
核心角色
每个架构活动都有一个正确、合理且可达的架构目标
而商业价值，则会帮助企业决策者和赞助者实现企业愿景
可以把整个架构活动引向商业价值创造。
同时，架构目标也会把架构活动引向用户价值创造，然后帮助到企业的用户
用户价值
最后，架构活动由于它本身定位的宏观性、规划的完整性和目标的长期性，还会产生其他的长期回报
比如对决策者、赞助者、执行者的决策效率、工作效率和个人成长的提升
那么这些角色最终也都会因此而更加支持架构活动。
长期回报
这将是目标确认和后续决策的重要输入
目标确认前的准备工作
决策者
赞助者
执行者
我们要确认架构活动的三个核心角色，
架构师在目标确认过程中的工作
19｜节点二：架构活动的目标为什么常常被忽略？
一个正确、合理且可达的目标，是靠多个职能之间反复讨论和反复演算得到的
是一个发现的过程，而不是一个拍脑袋决策的过程。
这种目标不同于自顶向下强行输出的目标
后者是出于战略而设置的目标，往往有正确性的保障，但却不一定合理或者可达。
好的目标制定的方法：
目标的制定要靠科学决策。
目标必须基于客观事实、自然规律和现实环境的约束。
作为架构师，你必须要为企业注入理智，用严密逻辑和真实数字来论证目标，而不是简单地相信
制定依据的理念
在确认目标的过程中，我们还要检查目标的合理性和可达性
相对来说，这个验证过程是一个快速的、基于经验和思想实验的判断，而不是一个耗时巨大的工程
确认目标时只需要和执行者确认一件事
在极限压力下，项目交付时间和 KPI 目标是可以被实现的，重大风险是可控的。
1. 执行团队不能为了减少考核和交付压力而故意压低目标。
2. 如果目标不合理，你需要代表执行团队向上反馈，把目标调整到一个合理范围内。
冒险往往是互联网企业的常用选项，所以准备预案这种方法，仅仅在少数已经处于垄断地位的互联网公司中会使用，其他企业很少会把宝贵的人力资源耗费在准备预案上。
3.重大风险需要有足够的预案，或者赞助者可以接受风险带来的后果，也就是赞助方支持冒险
过程中需要确保
目标的合理性和可达性
一个是输出符合 SMART 原则的正确目标（请参看第 19 课）
另一个是说服相关方放弃不正确的目标，重新设立一个正确、合理和可达的目标。
完成目标确认后，有两个可能的结果
很多处在职业初期的架构师会不惜一切代价去承接一个大的项目，误以为项目越大，功劳和成长就越大
从我的经验看，当你否定上级一个重大的错误决策后，才能真正成长为一个有主见的架构师。
在此之前，你只是一个被动的、缺乏独立思考的任务完成者
完成目标确认
20｜节点二：架构师如何为企业找到一个正确的目标？
为什么要做可行性探索呢
因而可行性探索的目的，就是让决策者和赞助者对架构目标是否可达，形成一个相对清晰的认知。
确认最终目标的可达（Achievable），也就是在企业的现有条件和时间约束下，目标最终可以被实现
任何一个架构活动都需要承受一定程度的风险，当某个风险确实发生的时候
这个目标实现的成本（时间、人力、计算成本等）虽然可能会增加，但目标依然可以在新的环境下被实现，而不是完全不可达。
可行性探索的过程不同于可行性分析（Feasibility Analysis）。可行性分析是一个非常耗时、详尽的评估活动
然而互联网时代，重在行动，所以我们用“可行性探索”这个词，来特别强调在这个节点上要控制成本，尤其是时间成本
成本
架构师需要在最短时间内发现最重大的风险，并对风险发生时的响应预案做出判断
与此同时，架构师也需要把重大风险披露出来，向赞助方确认是否能接受风险和预案。
在互联网时代，可行性探索的过程的王道就是从项目赞助者的视角出发，在赞助者的风险承受度之内选择做理智的冒险。
什么是可行性探索？
其实对于一个架构师来说，风险更多时候是一个筹码
如果能正确使用这个筹码，将会为自己换来时间和成功
反之，如果用错了，也将会让自己背上巨大的债务。
对于一个架构师来说，做风险选择是你为数不多的权利之一
我们职业生涯中能换来大量资源的筹码其实没几个，如果不知道怎么去冒险，那么相当于浪费了上帝递到你手里的筹码
而且，风险判断力不断提高的过程，也是一个架构师逐步走向资深的过程
1. 风险有多大？
2. 回报是什么？
3. 公司对风险承受度有多大？
4. 其他的选项的风险和回报是什么？
什么是风险？
不同企业对风险承受的差异非常大
有的企业鼓励冒险，有的企业则对失败的容忍度几乎为零，甚至会惩罚那些冒险的人
因而你的最终决策，必须与企业或者部门对待风险的态度相一致。
调查企业对风险的态度
赞助者的风险承受度往往比企业或部门的承受度要小得多，因此这是你冒险的下限。
赞助者对风险的承受度
领域专家指那些可以预见单个领域风险，并提供应对方案的人
你期望通过他的经验来帮助自己迅速锁定重大风险，找到最佳的风险预案，并准确评估预案实施的代价。
锁定可以提供决策帮助的领域专家
风险决策建议者这个角色，其实有点像法官
这个角色需要有全局的视角、有判断力、做事公正
你需要依靠他们的判断力，来提升自己的判断质量和决策质量。
锁定风险决策的建议者
我们的准备工作就是在企业风险决策环境方面做调研
工作内容
往往不能看到全局性的风险
哪怕是每个独立领域都没有风险，也不代表整个架构活动是可行的。
1.领域内部的视角非常狭窄
量化风险非常艰难，在“什么样的风险才算大”这个问题上，没有任何标准。
2.对可行性的估计没有任何全局标准
大多数互联网公司都是勇大于谋，过于相信速度和规模效应。在路径选择上不够丰富，在拒绝诱惑上也不够果断。
3.没有人愿意说“不”
面临的挑战
可行性探索前的准备工作
21｜节点三：如何通过可行性探索来帮助架构活动避免重大失误？
在这一步，我们需要从多个视角对重大风险做一个全面的挖掘。
在当前交付时间的约束之下，是否会出现研发动作和设计完全变形的状况（请参看第 20 讲）
当前的时间要求和资源投入，能否产出质量上可以接受的实施方案？
也就是说，实施方案是否高于质量底线？
多个参与项目的团队能否有效协同？
我们是否留出了足够的时间，让团队去处理集成中出现的问题？
第一个是项目交付的视角
比如互联网企业最容易发生的就是恶性竞争
是否存在会大幅影响最终产出的商业价值的因素？
那么怎么保障当某个大厂进入后，或者几十个初创公司入场后，我们的商业价值还能维持之前预估的水平呢？
本来很好的一个商业模式，会因为大量玩家入场最后变得无处逃生。
第二个是商业价值的视角
比如整个架构方案是否符合关键研发人员和目标用户的人性。
第三个是人性视角
方案上线后，会有足够的运营资源来帮助项目冷启动吗？
如果不存在这些运营资源，那么项目的预期产出还能保障吗？
首先是资源视角下的运营资源
企业内部还有什么正在筹划中的重大项目吗?
影响相关研发团队在你这个项目中投入资源的因素有哪些？
如果某个多方拼抢的资源不存在，那么项目的预期产出会发生重大变化吗？
其次是资源视角下的研发资源
假设你的项目是个技术驱动的项目，那么项目的长期技术价值有保障吗？
在新技术、开源和 SaaS 化的大潮下，项目的技术价值还会长期存在吗？
这些技术价值是你这个架构活动可以独立创造的，还是强依赖于其他项目？
最后是资源视角下的技术价值
指的是你这个架构活动的最小必需资源是否能够到位，主要包括运营资源、研发资源和技术价值
第四个是有限资源的视角
相对于整个企业来说，你的架构活动是否需要特别关注监管风险、法律风险和安全隐私风险？
有哪些风险会影响架构活动的可达性？
最后是其他风险
视角
从每个视角出发，梳理出来的重大风险最多不能超过三个。这个数量级非常重要
我们这个节点之所以叫做可行性探索，就是期望用最短的时间发现最大的风险，而不是要求你组织公司所有同事来做一个风险大扫除
这里的关键动作有两个，分别是“最短的时间”和“最大的风险”
在我看来，不论是多大的互联网项目，如果你花了超过 3 个人日才发现上述风险，那么你作为项目的总架构师其实是不称职的。
那么如何在最短时间内发现最大的风险呢？
一方面要靠自己的判断
整理好之后，再带着这些答案，与风险决策建议者一起碰撞，试图发现更大的跨领域的风险
这个过程与访谈十分类似。每人每次大概是一个小时的样子。一般来说，覆盖一个大项目的所有视角，也就是十几个人。
我想特别强调的是，在这个访谈的过程中，你个人也要有大量的思考和价值创造
你需要不断综合多个视角的输入，并进行加工与提炼
这样的话，每一次的访谈，都是在之前访谈基础上的更高质量的思想碰撞
这种基于高质量的思想实验来迅速得出重大风险的工作方式，就是风险发掘的王道。
强调
另一方面则要靠自己的关系网络。
重大风险的发掘
风险敞口预估并不是传统的风险描述、分析、建模、预案设计和评估过程（时间较长），而更像是思想实验
你需要对产出的重大风险逐一梳理，确认某个预案在理论上是存在的，并确保预案实施之后的大致体验可以接受。
1. 总时间成本。
2. 总人力成本。
3. 总资金成本。
4. 效果折损，也就是降级方案造成的商业价值或商业效果损失有多大。
一个方法是，通过用户的复购率降低值来量化用户体验的损失
另外一个比较客观的量化方法，则是保障用户复购率持平所需要的额外的营销购物券的总成本。
这样一来，你就可以把用户体验这样比较抽象的指标，量化成一个资金成本，只不过实施起来可能比较麻烦
5.用户体验损失
用如下几个参数，来量化你面临的重大风险
然后再针对每个备选方案进行组合，最后给出预案被迫实施后的估计值：
也许你会问，到底看几个才合适呢？
我们在这个环节只有一个目标，就是发现那些有必要叫停项目或者大幅更改整个架构活动目标的风险，这才是所谓的重大风险
其他的风险，其实都是架构师要带领大家克服的困难
所以真正大到能叫停一个项目的风险，是很少的。
从我的经验来看，一般一个项目最多也就两三个重大风险。
答案
风险预估
当梳理出重大风险后，不仅你这个架构师要持续关注，同时还要确保相关执行者也在持续关
当然，你没有权力来做这个同步风险的沟通，而是需要建议赞助者去这么做
一方面，不通知合作方是个绑架行为。
另一方面，合作方在知晓风险后，可能会帮你出主意，找到更好的解决方案。
建议
重大风险沟通
你已经收集了架构活动的重大风险和预案，也从全局上对风险有了比较深刻与全面的认知
收集、预估和排序的过程，其实也让你建立了一套全局性的风险评估标准
而且在风险评估的过程中，你肯定也收集到了决策者、赞助者和执行者的立场和风险承受度。
那么在最后的决策环节，就是将你收集到的重大风险、相应预案、参与者风险的承受度以及你所作出的建议，完整地表达出来
1.你需要站在决策者的视角上，作出一个对全局有利的决策建议，而不是从赞助者或者执行者的视角
互联网时代，时间是最稀缺的资源，所以冒险相对而言是更为有利的选择，不冒险反倒是个不负责任的表现。
2.要敢于冒险。
作为架构师，你需要对重大风险发生后的用户体验损失、商业价值损失等，进行准确的数量级的评估
同时，也要对预案能挽回的部分有个预估
一旦冒险失败，你还可以用时间来弥补。
3.冒险要理智
强调三点
最终，在这些信息的基础上，你需要给出一个可行或者不可行的总建议
可行性决策
架构活动中的可行性探索工作
比如最终对架构活动是否可行的判断，对风险承受度的矫正，对预案的改进建议
以及对架构目标和交付时间的调整，等等。
当完成上述工作后，你会得到来自决策者的几乎所有输入
如果项目可行，那么在进入架构规划环节前，你就已经对重大风险有非常清晰的判断了
毫无疑问，这会大大提升整个架构活动的成功概率
如果项目不可行，我相信你在探索过程中积累的判断能力、开放的心态和全局性的思维，也会给你带来新的甚至是更大的机会。
针对这些输入，你需要整理成架构文档，完整录入并分享给团队成员
完成可行性探索
22｜节点三：什么样的风险才算是重大风险？
需求确认
边界划分
架构规划。这个环节比较复杂，可以分为四个部分
统一语义到底是做什么的？为什么值得做？
统一语义听起来很简单啊，有什么挑战在里面吗？
我作为架构师，在这个环节中能创造出什么价值吗？
疑问
一是只有你一个人做项目，很清楚客户要什么，你也对整个项目流程有着非常明确的把握。
从自然语言到需求描述
再到域模型定义
接口定义
再到设计、实施、上线维护
都已经有了从完整的范式、数据字典、指标定义和语义冲突解决（conflict resolution）的流程
另一种是，你所在的公司已经有了统一的语义环境
统一语义并不是完全必须的环节。在两种情况下，你可以选择忽略这个环节
是当对话双方或者多方在各自表达，但却没有办法理解对方真实意图的时候，就需要统一语义了。
为什么双方在不断表达，却还是没法领会对方的意图呢？
根本原因在于对话双方或多方已经有了各自的语义环境（Semantic Context，简称语境）。
为什么要统一语义？
假设你正在主持一个国际化电商系统的商品中台构建的项目。
比如电影电视、歌曲、电子票等。
团队之前搭建了一个实体商品中台，目标是改造这个中台，让它支持虚拟商品的售卖
背景介绍
从商品中台团队的角度看，无论是数字商品还是实物商品，都是商品。
而从数字电商团队的角度看，此商品非彼商品，虚拟商品不是商品。
但是前台的数字电商业务团队和中台的商品团队吵得很凶：
一个实物商品源自一个生产商，这个生产商产出的是一个标准的产品（Product）
产品由不同的商家采购，在一个平台上售卖。在售卖前，商品被商家发布到平台上。
这些不同的商品描述被平台归一化，并与来自生产商的产品描述校准后，就形成了一个商品（Item）
这个商品会把搜索、推荐、秒杀等活动透出给用户，是用户认为他们能购买的东西。
当用户在某个商家的店铺里下了一个订单（Order）后，商家的履约团队就会完成订单。
把一个具体的货品（Inventory Unit），也就是商家从生产商那里采购来的产品，打包快递给用户
但实际上，商家发布的不是商品，而是该商家对自己所持有的产品的描述，也就是一个商品描述（Listing）。
入图所示
实物商品分析
一个数字产品（**Digital Product）源自一个发行商。发行商为平台提供一个商品描述 (Listing)。
这个商品也可以有搜索、推荐、秒杀等活动透出给用户，是用户认为他们能购买的东西
当用户下了一个订单**(Digital Order)后，商家就会进入数字化履约过程完成订单
把一个具体的数字内容（**Digital Content）和相关的授权密钥 （License key）分发给用户，那么用户就可在自己的设备上观看电影了
平台根据来自其他源头的信息（比如豆瓣评价）对商品描述做校准和增强后，就形成了一个数字商品 **(Digital Item)。
数字商品分析
似乎数字商品和实物商品的区别不大啊？那为什么两个团队之间会有那么大的分歧呢？
我们仔细研究一下这两段描述的语境，会发现其中有几个不同的角色，他们各自的语境差异很大
因而我们可以重新从各个角色的语境出发，再次审视上面的描述。
生产商是产品的生产者，提供产品的权威描述和售后保障等
他们一般不会与平台直接发生关系
当然，也有一种特殊的生产商叫做品牌商，他们会验证商品的真假
或者对商品的分销价格和领域等进行限制，因此会与平台发生关系。
不过在我们这个语境中并不涉及品牌商。
特殊情况
首先是生产商的语境
产品被商家以不同方式获取后，这个实物的产品就到了商家的仓库中，也就是未来要发送给客户的货品
那么商家将会控制这个货品的物权，甚至会在原有产品中增加额外保障，比如 7 天免运费退款、1 年换新等，作为商家提供的商品描述的一部分
可以说，商家和平台发生关系，就是通过提供对自己货品的商品描述。
第二个语境是售卖实物商品的商家。
平台在获取不同商家的商品描述后，会整合成一个平台的权威商品描述，也就是刚才提到的商品（Item），并把商品提供给平台用户
订单则是用户和商家形成的一笔交易。用户虽然把钱交给了平台，但物权还是在商家手里
用户确认收货之后，钱再由平台打给商家。需要注意的是，钱始终不属于平台，只是这个过程中的一个担保者。
第三个语境是实物电商平台。
用户在平台上可以购买实物商品，也可以购买数字商品
对于他们而言，花钱就是买一个能消费的东西（Consumable Item），能享受就行了。
第四个语境是平台用户。
拿电影来举例，发行商在某个国家或者地区内对这个电影有发行权
他们会为该地生产一个标准的数字产品(Digital Product)，也就是翻译好、剪辑好，并且按地区植入的相关内容的数字电影
除此之外，发行商也会和一个数字电商平台达成售卖协议，然后由这个数字电商平台向用户售卖数字商品（Digital Item）
第五个语境是发行商。
平台跟多个发行商都存在商务关系。发行商提供一个数字产品的版权，有的数字电视平台负责售卖
这个供应商和数字平台形成的是寄售（Consignment）的商务关系
从理论上来讲，平台上有无限的个人观看版权可以售卖，不过并不需要在一开始就给发行商一大笔钱
而是在用户下单之后，立即和发行商形成一笔背靠背的交易，采购一个观看版权，然后再把观看版权卖给用户
数字平台不是在售卖一个电影，而是这部电影在某个地区内不可以转交的、在限定时长内的、仅仅用于个人观看的版权，比如《沙丘》这部电影。
第六个语境是数字电商平台。
用户可能没有意识到，自己从来都没有买下《沙丘》这部电影，而只是买到了自己在某个播放设备上，且在一定时间内观看这部电影的权利
用户不能因为担心设备坏了而复制一份，也不方便把自己的手机借给朋友或者家人看，更不能截个短视频来传播获利。
第七个语境是数字内容的用户。
通过上述这些分析，你会意识到，一个平台中存在多个角色，而每个角色都有着从各自视角出发而形成的语境
同样一个词，比如商品或者售卖，在不同的语境下，语义很可能完全不同
有的角色在自己的语境内有着正确的定义和自洽的逻辑
但是有的角色，比如说用户，可能都不知道自己得到的数字商品，其实是带有很多约束条件的一次性的授权
在他们的语境之内，数字商品和实物商品都是商品，没有什么差别。
对于用户来说，不论购买商品还是购买数字电影，都是付了一份钱，得到了自己需要的东西。
但是大多数角色都不一定知道其他角色的存在，更不用说理解他们的语境了。
一个词，比如商品，你与周围人都在使用。但这个词的真实语义，却因为使用者角色及其语境的不同，在不断切换
如果你不知道其他人的语境，那么你们就是在不停地对话，而不是真正的交流。
每个角色真正最在乎的，其中只是自己的需求被准确地满足，而根本不关心其他角色在表达什么。
各个角色语境出发，解释原因
为什么会有语境差异？
项目所有参与方的需求能够被无损地表达、记录和传递，然后通过架构活动实现出来。
这个角色的全局性，就意味着你需要看到不同角色之间的语境的差异
然后通过一个完整的、自洽的、相互兼容（Interoperable）的设计，来满足所有角色的诉求。
这一点对于架构师来说尤其重要，因为你在整个架构活动是跨越多个角色而存在的
统一语义的终极目标只有一个
1. 架构活动的目标，能够清晰传递并分解给每个参与者；
2. 所有参与者的诉求，能够被准确地表达、记录和传递；
3.架构活动的目标和所有需求能够反映到整体的架构规划中，并且能够被无损地拆分到多个子领域的任务中；
4. 需求方能得到执行者的真实反馈，从而对整个架构活动的产出有个合理的期望；
5.每个子领域交付并组装好之后，能够语义契合、相互兼容，最终符合架构活动的整体目标。
因为有了统一的语义，你才能保证：
你要确保所有参与方都在使用同一个语境来表达自己的需求，确认自己的责任。
你作为架构师，要确保从顶自下的目标的正确性、合理性和可达性
然后在统一语义的环境中，构造和确认需求、划分边界、拆分任务，并确认整个架构规划的完整性。
最后，你需要跟每个执行者确认他在架构规划所要承担的责任，帮助需求方和执行者把这些内容撰写成一个交付合同，并让各方确认，完成自己的工作
在联调阶段，又重新组装成完整的系统，最终最小化跨团队的交付风险，达到预期目标
从某种角度来说，架构师在架构规划中扮演的是律师的角色
统一语义的目的不是为了统一参与者日常工作的语言，而是确保整个架构规划在一个逻辑完备且语义一致的环境中
能完成架构规划全生命周期的信息流转。
架构师在统一语义中的价值
23｜节点四：架构规划之统一语义
这张图里有多个角色，每个角色都有自己的语境。
在两个角色的交互过程中，通过统一语境的过程，又出现了新的语境。
语义环境的差异
假设物理世界有一个存在（Being，名词），也就是图中的绿色部分
那么主体，简单来说就是你和我。
我们可以在各自的意识中对这个“存在”形成认知，也就是图中的客体。
唯物主义者认为，存在是先于主体和客体的。
而且是客观的，独立于我们的意识而存在的，不以你我的意志为转移的。
唯物主义
而主观唯心主义者认为，只有你我意识中形成的客体是真实存在的
而那个“存在”却不是第一性的。
主观唯心主义
对比
我们各自主观意识中形成的客体，
以及我们能表达给其他人的关于客体的描述
以及我们试图在多个人中间建立的对这个存在的共识的认知
这三者是不等价的。而这种不等价，就是语义分歧的根源。
互联网企业一般是跨国企业，员工的文化、语言和认知本身就有差异。
互联网企业的组织复杂度大，不同角色有不同的视角，他们的认知也有差异
比如说一件商品，在大促、秒杀、团购、社区团购、物流履约和售后的场景下，含义会有所不同
互联网企业的场景跨度很大，在不同的使用场景下，语义也会发生变化。
由于语境多样性而造成的语义差异，在互联网企业中更为普遍和严重。原因如下
语义分歧的根源
每一个交互场景其实都存在着多个角色，每个角色都有自己的独立语境。
比如商家从供应商那里采购实体商品这个场景，就有它的独立语境
而商家给供应商打款，虽然交互双方没有变化，但是新的场景又会带来的语境。
第一步，发现不同的语境
一旦发现了一个新的语境中，存在词语表达相同但语义不同的概念，那就需要准确描述这些概念了
就像我们上节课给出的例子。你不但要给出一个概念，更要准确描述这个概念背后的场景。
第二步，定义概念。
当完成了单个概念的定义后，就需要把不同概念引入到同一个语境中，也就是将两个不同的语境进行合并
图中绿色的部分，也就是被融合的实体的语义，需要与融合前语境中的语义基本保持一致。
而蓝色部分，指的是每个实体有各自的语义，则需要保留。
这个过程，其实就是把上节课给出的两张图合并成一张图
第三步，语义建模。
一旦形成了统一的语境，你就需要跟所有参与者确认这个统一语境的正确性。
要时刻记住，你作为架构师并没有什么特殊之处，也只是一个独立的个体
你的认知也仅仅是存在于自己语境中的认知，所以必须要与所有人重新确认并多次调整，才有可能找到基本正确的统一语境。
第四步，反馈修正。
指的是不断使用和打磨实体定义，最终为企业带来统一语境
这个过程就是从自然语言、到需求描述、到域模型定义的过程，未来也会延申到接口定义、模块设计、代码实现、上线使用等。
第五步，公布、维护和使用统一的语境
最终，这些过程都对之前的定义形成反馈闭环
如果你把语义的定义和维护做到极致，那么它就是一个基于标准化、中央化的实体定义和数据字典，以及围绕这些定义而制定的语义冲突解决（Conflict Resolution）的管控流程
也就是说，你们最终会建设一个完整的语义管理体系。
我们讲建模，其实已经默认所有的客体都放在了同一个语境中
我们也不再区分不同主体视角中的客体，而将它们统称为实体
但是实际上，建模过程中最难的一步，就是从不同语境中的主体那里，推导出一组统一语境中的实体。
建模需要注意的
如何消除语义的分歧？
24｜节点四：如何减少语义上的分歧？
需求确认与统一语义的过程是密不可分的
需求确认是在统一语义赋能之下进行的，所以两者并不是先后顺序的关系。
统一语义的主要场景和目的，就是对目标进行无损地分解和传递，以及理解、表达和传递参与者的诉求
那么需求确认，则是在统一的语义之下，将这种诉求继续无损地分解成研发人员的执行任务的过程
在公司内部，站在客户身后的受益人一般就是这个架构活动的赞助者。
不过也有的赞助者是站在用户身后的。
第一是客户，也就是为你整个架构活动买单的人。
比如我们上节课提到的商家
发行商和平台运营
包括常规的用户角色
比如某个 SaaS服务
也可能是某个银行金融授信的自动化审批的角色。
还包括代理角色
所以用户是指整个架构活动设计需要考虑到的所有内外部的用户角色。
第二是用户，他们是最终产出的软件产品的使用者，也是你创造的用户价值的受益者。
比如客户 / 用户在这个架构活动中的核心诉求是什么
他们因为什么价值而买单？
这些需求将会在哪些场景中出现？
第三是核心场景
首先要从产品定位的角度来梳理
你需要确认他们将会为哪些用户角色服务，可以为这些角色创造什么价值。
第一是执行团队，也就是架构活动的相关执行团队。
你特别需要关注的是执行领域之间互相重叠的部分，以及没有被任何执行领域覆盖到的部分。
第二是执行域划分，也就是每个执行团队所负责的领域。
除了架构活动中已知的执行者外，整个公司内部，谁应该、谁愿意、谁有能力或者谁有带宽承接某个需求呢？
第三是需求承接方
其次要从执行者定位的角度来梳理。
比如不同需求方的优先级，是按什么规则来排序的？
第一是需求优先级的决策信条
哪些需求是必须完成的？
需要注意的是，这些并不是单个角色视角上的必保需求，而是由参与方和决策者达成共识的必保需求。
第二是必保需求
架构活动肯定会为公司带来新的外部适应性，那么外部适应性将会在哪里创新，怎么度量，谁来承接，等等
这些都是你这个架构师要必须完成的工作。
最终，这个隐含需求也要被显现地表达出来，也需要跟其他需求一样，有执行者，接受取舍。
第三是隐含的技术需求
你应该从决策者和赞助者那里来确认如下信息
最后是取舍规则，
需求确认前的准备工作
一个大的架构活动会有几千条需求，有好几百人参与开发。
如果你把需求一条一条都映射到执行领域中，那将是非常繁琐和低效的过程。
需求确认的过程，也是从问题域到执行领域的映射过程。
多数需求可以由产品经理或者 PMO 整理到不同的问题域中。
而你这个架构师需要做的，就是把问题域映射到执行域上。
你并不是把上千条需求分配给几百个研发，而是把几十个问题域映射到几十个执行域中
在这之后，就是逐层分解了。只有在边界模糊的场景下，才需要你这个架构师的介入。
如图所示：问题域的划分方法
绿色，代表数字和实物商品整合之后的商品域；
古铜色，代表实物商家域；
蓝色，代表发行商域；
紫色，代表货品和履约域；
而黑色的部分，则属于数字商品域。
不同的颜色代表不同问题域的划分；
也就是说，如果你把这张图复制一份，就可以在每个问题域上标注出相应执行团队的名字。
在一个合并后的公司里，你会看到一对多的情况；
在一个收缩的公司里面，你会看到多对一的情况；
在一个架构和管理混乱的公司里，你也能看到多对多的情况。
当然也有粒度不同的情况存在
假设你整合了两个不同的部门。那么整合之后可能会发现某些问题域有多个执行域，也就是踩脚的情况
当然，你也可能发现某些问题域没有任何已知的执行域，也就是新建或者烂尾的情况。
这都是整个架构活动风险多发的领域，你必须及早发现，及早处置。
步骤：从形成统一的问题域模型，再到问题域划分，最后到执行域的划分，一次迭代肯定没法完成
而且，一个实体往往不会正好映射到一个执行域，而是会因为各种历史原因形成错综复杂的映射关系
多数时候，问题域和执行域都是同构的。
核心的问题：问题域的定义
在最开始的时候，我们就要把问题域定义出来。
如何做？
问题域划分
在这个环节，你需要从架构活动的整体目标出发，确认需求存在的必要性
作为架构师，你需要准确区分最小必要的需求和无关紧要的需求
只有那些与项目目标形成因果关系的强依赖需求，才是属于架构活动的需求。
如果没有领域划分，那么你还需要砍掉附加需求。估计你这个架构师很快就混不下去了。
要知道，砍需求是个非常得罪人的事情。你做这件事情必须要有个同盟，也就是与需求对应的、问题域映射到执行域的负责人
因为在砍掉不必要的需求上，你们两个人的利益是一致的。你为了整个架构活动的成功，他则是为了控制自己领域的风险。
你可以站出来表达比较客观的立场，而他则可以帮助你证实这个立场的合理性。
这个梳理过程，之所以要放在问题域和执行域划分之后，是因为需求属于问题域的范畴，而需求的执行则属于执行域的范畴。
这个需求绝对有必要吗？与整体目标是因果关系吗？
无论这个需求的价值有多大，只要它不是架构活动的必要条件，那就应该分开考虑，最好完全隔离在架构活动之外。
第一是需求的必要性
需求是否和架构目标相匹配？
想要得到赞助者所期望的商业价值，那你这个需求目标的正确数量级应该是多少？
如果一个需求的预期目标，比赞助者所需要的值还要小一个数量级，那这个目标就是不正确的。
第二是需求的正确性
在当前交付时间的约束下，需求的交付时间和质量要求是否合理？
是否会出现研发团队动作和设计完全变形的情况？
第三是需求合理性
当前的时间要求和资源投入，能产出质量上可以接受的实施方案吗？实施方案是否高于质量底线？
如果某个需求需要多个团队协同，那么我们能留出足够的时间，让团队处理集成中出现的问题吗？
第四是需求的可达性
这个需求有且仅有一个团队承接吗？是他们应该承接的吗？
他们愿意吗？能力够吗？有研发带宽吗？
第五是需求的承接方
关注点应该放在如下五个方面
评估需求
当梳理完所有需求后，我们还需要将那些满足最小必要条件的需求，整理成一张从需求到承接的关系映射表
你需要跟每个执行团队，逐个确认他们是否是某个需求的承接方，这是你这个架构师在架构规划前必须确认的大图
因为你需要有足够的信心，来保证从目标到需求、从需求到核心场景、从核心场景到问题域、从问题域到执行域的映射，可以被无损地表达且没有冗余。
后续
你会发现有些需求有好几个承接方，而有些需求却没有一个承接方。
有些高优先级需求的对应执行者，没有任何研发带宽
而有些低优先级需求的对应执行者，却有充足的带宽。
这个映射是对事实的反映
需求到承接的映射
在统一语义的过程中，你会发现不同角色在不同的语境中隐藏了很多冲突
日常工作时这些冲突可能并不明显，因为大家都在自己的隔离语境中与几个团队进行了小范围的合作。
直到我们把不同语境中的概念，拿到一个统一的语境中来抢夺有限资源的时候，这些冲突才会全面爆发。
其实越早暴露这些冲突，对于架构活动来说越有利。毕竟这些冲突是客观存在的，避免不了。
这是互联网企业最普遍的冲突，在资源有限的情况下，每个需求方都从自己的视角出发
期望得到最大的支持，导致各方在需求优先级上无法达成一致
比如营销团队，由行业运营和大促运营两个团队共享，而每个运营团队都认为自己的需求优先级更高
这就是多个依赖方共享一个开发团队导致的。
第一，优先级的冲突。
不同角色之间天然就是互相制约的，这并不是特例，而是企业中普遍存在的现象。
因而一个企业内部必须有某种形式的监督和制约机制，以确保整个企业的决策有完整且相对平衡的视角，而不仅仅是单一视角中的最优
商家运营的定位是商家增长，那么这个角色就要吸引尽可能多的商家到平台上
而网规团队的定位是减少平台风险，那么这个角色就要尽可能地打击作弊和劣质商家。
从算法的视角来看，前者的定位是要最大化召回，后者的定位则是最大化精度。这就是一对矛盾。
第二，定位的冲突
团队或者个人之间也会有敌对情绪
有的公司喜欢赛马，针对同一个垂直领域，会让几个部门用不同的商业模式在市场上竞争
或者针对同一个场景，会用多个技术和算法来实现。
第三，团队和个人的冲突。
多个需求方或者执行团队负责的领域边界不够清晰，不确定到底“谁说了算”
比如商家团队和商品团队之间，交易团队和资金团队之间，流量团队和导购团队之间。
1.不同垂直执行域在定位上本身就有重叠。
比如前端团队和后端团队之间的分层
业务团队和财务团队之间的分层。
2.水平分层上的模糊性
比如前端转全栈工程师，导致前端的职能范围拓展到后端去；
业务中台化，导致业务线的研发任务迁移到了一个共享的中台里去
前端低代码化，导致之前由前端执行的任务，变成了由产品或者后端工程师来完成。
3.因技术进步带来的执行域边界的迁移。
主要源来自三个方面
第四，边界冲突
需求方到执行者领域的映射关系没有形成共识，导致几个团队互相争夺地盘。
比如上面那张图中的商品，会与数字商品整合成一个商品执行域，从而形成多个业务团队映射到一个执行域的情况。
如果产品团队已经完成整合
产品团队
但是技术团队的整合还没有完成，那么订单域就可能形成一对多的映射情况
技术团队
这种一对零、一对多、多对零、多对一、多对多的状态，都会造成设计和执行过程的混乱，必须在这个节点解决掉。
第五，问题域到执行域的映射关系的冲突。
这是映射冲突中一对多和多对多的情形，在大公司里比较常见，所以值得单独列出。
比如一个部门里有多个做网关的团队，平时大家都相安无事。
一旦公司要把几个网关合并成一个，那么生存空间的冲突就不可避免了。
第六，生存空间的冲突。
在规划和执行决策上，有的角色非常强势，导致本来属于架构师的决策权
却被某个领域的领导抢夺了，从而形成架构冲突的热点
对某个领域有控制权的共享技术团队，涉及到他们管辖的领域，需求必须由他们承接，设计也必须由他们决定，谁都不能替代或者更改
这就导致任何由这个团队参与的架构活动，一旦涉及这个团队的需求，设计就全都变形了。
比如某个大厂长期存在这样的现象
第七，决策权的冲突。
几种冲突
问题域和执行域中的冲突
1. 多个团队争夺有限的资源；
2. 多个团队争夺生存空间；
3. 无法调和的个人与团队之间的矛盾；
4. 短期内不合理的组织和决策结构。
四个棘手的问题
如果没办法缩减交付项，那么必须在这个时间和赞助方、决策方、参与方讲明白
要么调整质量预期，要么调整上线时间
1.对于有限资源的争夺
务必请决策者迅速裁决。因为这是没办法调和的冲突
2.对于生存空间的争夺
如果活动还没开始就没办法相处，可以预见，随着项目压力的增加，矛盾必然会放大。
我建议还是请决策者进行处理。
如果没办法处理，也要请决策者提前指定一位裁决人。一旦出了问题，你能迅速找到裁决人进行拍板
3.对于个人与团队之间的矛盾，我认为只有躲开才是上策。
可以通过我们前面讲的搭建架构环境、设立决策信条等方法予以解决。
不过我觉得最好还是请相关参与者和决策者一起，来制定和确认一些决策信条。
4.对于组织和决策结构的问题
相关的建议
总的来说，执行域划分是个压力非常大的环节
你这个架构师也必须保持开放心态。在这个过程中，你需要充分表达，大胆建议。
你与决策者所拿到的信息是不对称的。大多数时候，你看不懂，只是因为你的视角有限
换句话说，你与其他参与者一样，各自的视角都是片面的
那么人才培养、团队稳定性、成本控制、商业竞争、监管，甚至是国家间的关系，都可以成为边界划分的理由
你可以不认同决策者的判断，但千万不要下意识地阴谋化别人。这个世界没那么多阴谋，多数时候大家都是见招拆招。
不过也要注意，你并没有决策权。你提供的仅仅是技术视角，而不是整个企业的视角。
当然，如果可能的话，你应该试图理解每个参与者的视角，并对最终的执行域划分给出一个合理的解释
一个让参与者，如果能主动接受领域划分，那将远远好于自上而下的强制性的边界划分。
确认
从问题域到执行域的领域边界划分
完成需求确认
从项目目标到需求的映射过程
25｜节点四：架构规划之如何进行需求确认？
上节课我们讲到了从问题域到执行域的映射，是个粗粒度的映射关系
不过有些任务无法在粗粒度的划分下完成需求到执行的映射，比如我们上节课提到的边界冲突的情况。
粒度划分是基于现有执行域的，这种划分导致我们的架构设计会受到执行团队组织结构的约束。也就是康威定律对架构设计的干扰。
无论我们怎么努力，依然会在架构活动中碰到执行域划分没有执行团队，或者有多个执行团队的情况
执行域是非常粗粒度的任务划分，但部分有边界冲突的跨领域任务，需要在更细粒度的任务层面上做执行边界的划分。
这种粗粒度的映射会面临三方面的挑战。
那么如何应对这三方面的挑战呢？
我们可以把这些需求拆分成研发任务，并分配给执行者
而这些任务的组合和边界，最终会决定长期的技术架构
因而这个步骤，可能是架构师能对长期架构设计产生最大影响的一个环节了
所以深度理解从需求到任务到承接的关系，以及学会如何分配自己的注意力，就是你这节课要掌握的重要技能
进行任务边界的划分
需求是一个问题域概念，来自用户；
任务是一个执行域概念，来自内部的分工合作
需求和任务的区分
任务分配虽然应当尊重当前问题域到执行域的映射，但却不需要完全遵照这个映射
在一个架构活动中，架构师更应该从用户思维出发，把任务交给能完成这项任务的团队。
在这个短暂的架构活动中，你作为架构师应该有任务边界划分的全部授权。
演绎
我个人就有过类似的经历，需要与多个部门的大佬合作，去进行公司的一个大改造
但我没有获得任何任务边界划分的授权。
最后的情形就是，这些大佬的确派了团队来参加架构活动，但是他们所有的代码与设计，一律向各自的部门看齐。
信条一：任务边界可以打破现有的执行边界。
任务边界划分有多种方案，这就意味着你必须有一个甄别方案优劣的决策逻辑
这个逻辑决定了你在多个划分方案之间，将会如何打分或者排序
1. 最大化项目目标的完成度；
2. 最大化技术方案的结构性；
3. 最小化整体成本；
4. 最大化团队的长期稳定性；
5. 最大化团队的短期稳定性；
6. 最大化决策者或者赞助者的满意度。
常见的选择是
比如在缺省的情况下，我建议你将第一个选项作为这个信条的核心部分
信条二：任务边界划分以最大化项目目标的完成度为第一优先级。
场景一
哪怕你被决策者明确告知，应该用另外一个选项作为这个信条的一部分，那么第一个选项也可以作为一个约束条件
信条二：任务边界划分以最小化整体成本为第一优先级，但是不能牺牲项目目标的完成度。
场景二
在给定的架构活动目标之下， 要以最大化架构活动的成功来做任务边界划分。
span style=\
信条二：任务边界划分有确定的决策优先级
架构师经常有做抽象的冲动，导致架构设计中经常会出现不必要的抽象。也就是大家常说的盖楼倾向。
从我的经验来看，在一个高速迭代的互联网业务中，业务探索的方向变化大，模式更迭快，多层架构抽象往往是得不偿失的
而更好的办法则是做阶段性的重构。
1. 前者是在业务模式还没有稳定下来之前做架构抽象。
2.后者是在业务模式已经稳定且有明确浪费的情况下，然后对重点领域做针对性的重构。这就是重构架构目标之内的抽象
多层架构抽象与阶段性重构这两者的区别在于
抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性
我非常反对没有任何数据支撑和可度量目标驱动的架构抽象
这个信条的核心就是不要在架构活动中制造出新的抽象任务。
这个信条的价值在于简化架构规划的内容，减少执行者的工作量。
信条三：最小化架构目标之外的抽象
任务梳理是一个自顶向下的过程，要求我们不能停留在表面的理解上
而要抽取出核心实体，以及针对这些实体的相关操作，并把这些操作隔离出来。
隔离是把两个实体的相关的任务分开来，确保独立封装和实现。
而抽象是在两个实体之上抽象出第三个实体，共享部分任务和实现。
有的人分不太清楚“隔离”和“抽象”，这其实是两个完全不同的概念：
我认为抽象这件事情可以后置，等业务稳定了、看清楚了再说。
而隔离则不能等，要尽早做。
因为隔离后的实体和操作，未来都可以被分别抽象。而对于一个巨石应用来说，就只能做重构了。
你或许能发现第三和第四条信条是有共通之处的，它们的核心都在于不用过分抽象，但必须要隔离。
信条四：任务边界划分时要最大化隔离
作为架构师，要明确知道你的引导会对技术和组织边界产生哪些长期的影响
所以在任务边界划分时有一个至关重要的问题，那就是怎么运用康威定律：“设计系统的结构和产生这些设计的组织的沟通结构是同构的”
而这种最优边界是面向未来的最优，是能够最小化未来团队间依赖的边界划分策略
因为这是基于用户需求的变化，基于技术趋势、竞争态势和数据模型的演变而得到的。
如果财务团队从来没有与平台商家团队有过沟通，意味着这两个系统还没有打通
那么财务团队为企业建设的业财一体化的进销存能力，就不会把平台商家作为一个可能的用户来考虑
与此同时，业财系统也不会被设计成多租户，以撬动商家提升企业的资金效率。
信条五：任务边界划分要面向未来最优
从用户需求出发，在架构目标统一的信条下，最终达成切实可行的、从需求到任务到承接关系的划分。这才是边界划分的王道。
其他信条
具体怎么做任务边界的划分
26｜节点四：任务边界划分应该遵循哪些信条？
有些架构师很少关心从用例到任务的分解过程，认为这就是产品和相关技术人员的事情。
事实上，这是你这个架构师为企业注入思考的核心切入点：从技术角度来理解这些用例对现有或未来架构设计的影响，然后再在任务定义上体现出你的思考。
我们做技术是为了服务用户，那么给用户提供的服务的精细程度、服务质量、迭代速度，都必须保证能赢得竞争才行
这也意味着架构师的取舍不是一个艺术，而是一个基于商业和技术环境的理性的思考决策。
任务梳理和粒度控制
大多数时候，你都不是从零开始做一个新系统，所以产品用例往往已经有了现成的从需求到执行方的映射关系。
但这也不妨碍你从用户视角出发，从全局去思考最优的、从需求到任务再到执行者的映射。
无论是已有的映射关系，还是尚未确定承接方的新需求。
1. 在独立性假设之下，任务分配是个局部优化的过程，所以不需要在全局上做优化。
2.在独立性假设之下，真正导致失败的正是你的最软肋，也就是架构活动中成功概率最低的强依赖。这是架构师最重要的关注点，而不是大家都在注意的光环点。
大促的交易营销链路就是一个光环点，但是往往大促出问题的地方不是交易营销链路
而是类似获取物流费用这样一个下单页面的强依赖
分配调整的重要结论
那么什么东西会影响单个任务的成功率呢？
这个任务的目标设定、设计方案、用人、研发测试资源、运维环境，这些影响整个架构活动的因素
不过这些因素，在一个更小的任务尺度下同样生效
不太主张在任务梳理、粒度控制和任务分配环节里，有太多的脑暴和发散。
因为此时此刻，我们已经进入到执行环节了，那么就要尽量减少分散注意力的动作，尽快作出决策。
边界划分和任务分配
一旦任务边界确认，那么就必须迅速锁定所有必保需求相关的资源
除了研发人员外，还包括业务、产品、研发、流量入口、发布窗口，甚至营销资金池。
一旦确认了项目的可行性，请立即把大家聚在一起去做技术规划
当然，在这个过程中，我也会做一些动员工作，告诉大家项目中都有哪些机会
其实就是我们常讲的“画大饼”。你可能觉得这么做没什么用，因为人人都在画大饼。
我的个人经验是，项目的成功概率跟参与者的意愿度和投入度的关系更大一些，跟这个人的能力关系略小一些。
锁定项目必保需求的交付资源
需要注意的是，在实际执行的过程中，你往往会漏算，也会碰到突发事件，比如需求方会更改他们的需求。
一来，你会及早发现更多细节和不自洽的部分
那么在这个过程中，你还需要不断迭代任务分解，尽量把用例从粗到细做成多层分解。
完成边界划分
27｜节点四：架构规划之如何划分任务边界？
是控制风险的重要机会。
是保障交付的重要手段。
因为在这个环节，你和其他参与者会产生大量的规划文档
而这些文档，就是沉淀知识的利器。
是为团队和企业沉淀知识的重要时机
价值
在规划确认之前，你已经收集了几乎所有与架构规划相关的文档
那么规划确认，也就是定稿架构规划文档的过程。
说明
在定稿的过程中，你可能会和不同团队、企业外部专家产生诸多交互。这个时候你就需要与执行者确定规划内容
因为之前的收集主要是作为规划的输入，而不是执行者的承诺。
所以你就需要把输入转成一个可行且有约束力的规划。
定稿架构规划文档
用例文档是关于交付内容的最简洁的描述。
它的作用是描述架构活动中某个团队或者小组要为某个用户角色，在某个场景中，创造出某种价值
商家团队要为中小商户，在店铺经营过程中，提供有明确行动点的生意参谋功能，从而提升商家的经营效率和成交额
需要格外注意的是，无论是写用例，还是用一张图来表示用例，都需要避免堆积
在一个架构活动中，不论是十个人还是上百人参与，最顶层的用例最多也不能超过十个。
确保所有研发人员都能对各自所交付的单元目标有清晰的认知
对用例的描述除了要尽量简洁外，还要将其整理成一个文档。这样的话，几乎所有人都能通过阅读这些用例来获得更为宏观的视角
而具体的每个场景的细节描述和需求文档，可以通过链接记录到另外的文档中。
这些用例描述的作用是，
组织用例文档
在架构规划的环节，我们还需要重新梳理一遍在任务边界划分中，做出来的具体的任务描述。
并且要确保这些必保任务录入到了 Jira 之类工具中。
借助这个工具，我们需要收集所有必保任务，并确认任务分配和交付排期。
最终，我们需要通过这个工具来跟踪所有必保任务的交付情况
需要注意的是，这些必保任务也要和用例形成关联关系。
另外，你必须让最终的执行者来确认领域模型。因为之前帮你起草领域模型的，不一定是最终的执行者。
确认必保任务的交付节奏
同样，在这个阶段之前，你准备的领域模型也是一组输入
那么在规划确认这个环节，你就需要完成定稿。
这是一个统一语义的过程，整个架构活动只能有一个问题域模型。
虽然不同的执行者可以帮你梳理领域模型，但是你必须把整个领域模型整理到同一个语义环境中。
确认领域模型
有了用例文档、必保任务和领域模型，接下来就可以请各个团队完成 API 设计了。
有约束性。我们刚才把架构师在这个环节的角色看作律师，那么我们就要看看执行方能提供什么样的服务。
易读易用。对于大多数程序员来说，读代码要比读文档更便宜。
研发人员非常在意自己的口碑，一般比较资深的研发都会在 API 的定义上面下很大的功夫。
不像 Wiki，很容易变成一个 Group 文档
有 Copyright 和 Ownership。
连 Swagger 都不想写或者写不出来的人，估计你未来也很难撬得动他，甚至也用不上这样的人
所以在 Swagger 上的投入，能让你提早发现资源和能力上的问题。
有投入度
5. 规范性好，很容易在团队中标准化掉。
6. 可测试性好，容易验证其完整性。
长期回报大。仅架构活动本身，对定义者本人的价值就很大，可以帮助他想清楚问题。
Swagger
工具
确认 API
也就是某个角色在某个时间能为某个使用方提供某些消息和数据。
尤其对于一个体量较小的公司来说，消息队列带来的编程、维护、状态查询和故障恢复的复杂性，一般来说不值得采用这样的设计
小公司
不过在大公司里，消息的确是一个非常不对等的合作机制
往往是某个负责核心实体的团队比较强势，通过消息机制和其他服务解耦来降低稳定性的风险。
大公司
很多公司的消息机制缺乏规范性，治理起来又非常困难。因而我不建议你把消息机制作为一个数据传输的首选机制。
确认消息和数据流
所以确认强依赖任务的交付节奏，是你这个架构师、项目经理和执行者在各个用例层级上都要进行的任务
确认强依赖任务的交付节奏
整个架构规划的完整性确认，需要测试和相关团队核心人员的介入，从而确保核心场景的核心用例能被现有的功能所覆盖。
同时也要确认 API、消息、数据是完整和兼容的，整体集成风险是可控的。
在这个环节，我一般不太关注边界条件的梳理，主要是担心大家会把过多的注意力分散在较小
甚至是比较难的异常情况梳理上，而在核心场景和强依赖任务的梳理上投入得不够。
确认整个架构规划的完整性
八个部分
最终我们要达到的结果是有人有图有承诺，这才算是合同签署完毕
需要注意的是，这张图要尽量完整，每个模块都有一个 Owner，也就是我们在边界划分里确认的执行者
我会在某年某月的某一天，完整交付你可以依赖的完整的一条边
每一条边，不论是 API 调用、数据流，还是消息机制。都会有一个人承诺
28｜节点四：架构规划之如何确认规划完整性？
项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认。
不过“签约”之后，不是说自此之后再也不能更改这个合同中的条款了
而是指有了承诺，任何参与者都不能单方面更改条款，需要通过一个确定的流程才能更改。
在互联网时代，项目启动环节的王道是以终为始，公开架构活动的明确目标，以清晰的语义阐述参与者的责任、权利和架构环境，保障参与者对目标的全力投入。
确认并锁定运营资源、产品资源、技术资源和数据资源。
1. 资源环境：
将之前搭建的架构环境，尤其是架构信条的细节，整理成完整的线上文档，并共享给其他参与者。
2.架构环境：
完成整体的架构规划，初步完成不同领域的细节规划文档。
3. 架构文档：
梳理好整体和各个领域的风险，完成已知的重大风险预案。
4. 重大风险：
1.准备的四个方面
多数沟通停留在口头，设计文档不存在或者不完整；
核心领域和强依赖中有大量仍处在争议状态的设计评审结论。
2.缺失技术细节
整体的架构方案，跟一个或者多个细分领域的架构方案有冲突
3. 架构方案互相冲突
多数互联网公司不怎么区分大项目和日常需求，导致对大项目的技术风险评估过于简单和乐观
而这些大的项目，可能会因为系统复杂度高而导致失败。
4.隐藏的技术风险：
某几个领域的资源无法保障 100% 的投入，只表示“尽力而为”。
5. 资源不确定：
部分执行团队之间的任务边界模糊，这也是第 26 讲提到的任务边界划分尚未完成的情况。
6.边界模糊
这一次是玩真的，所有执行者要在承诺书上签字画押。
架构的正确性验证，本来就是一个自顶向下分解，随着项目进展和环境的变化而逐步细化的过程
项目启动呢，又是一个重大的状态变化的过程，意味着架构规划的确认将从非正式变成正式
架构方案的正确性验证，
在项目启动环节，我们真正想达到的是深度握手。
各个参与方对所达成的架构目标、架构方案、架构环境、任务边界、交付节奏，以及资源投入，完成一次有约束效应的正式握手
除了要确认我们在统一语义环节中达成的架构目标与架构方案外，还要从技术层面对每个子域的技术交付内容做正式的确认
架构师需要做的，就是从技术视角出发，自顶向下验收所有子域的方案。
技术交付内容的正式确认
解除重大风险的具体做法，跟我们之前在可行性探索环节中的风险决策方法相同。这里就不重复了。
不过你要是对这些项目仔细研究的话，会发现它们都缺乏高质量的逻辑论证。
要知道，一个有过专业训练的架构师至少是可以发现这些重大风险的。
也就是说，这样的损失是可以避免的。但是就像生活中的许多行动一样，放弃需要勇气。今天的放弃是为了避免明天更大的损失
重大风险解除
就是在架构活动启动之后，有一个畅通的沟通渠道，来确保重大问题能被决策者注意到。
比如项目经理通过项目日报或者周报对风险逐层上报，就是一个很好的方式
从技术角度来说，统计数据、需求完成进度、Blocking Bug 的数量、集成测试的进度，都是很好的预警指标。
预警的价值就在于机制本身的客观性。
问题预警机制
就是在两个或多个合作方之间出现争议，并且无法化解冲突的时候，需要紧急启动的升级决策流程
虽然这种决策方式可能会导致重大失误，但在互联网时代，时间是最稀缺的资源，这种决策方式的时间成本是最低的
一般的做法是几个人小范围讨论，如果不能达成一致，就需要升级到更高层级再次讨论。
如果依然达不成一致，就需要升级到决策者，形成一个最终的结论。一旦最终结论形成，各方须立即执行。
冲突解决机制
那么搭建的预警和冲突解决机制，就是要确保所有参与者不会把技术问题“政治化”，确保重大问题不会被隐瞒，冲突不会被长期拖延
在这个过程中，你要向所有参与者传递一个态度：技术问题和团队冲突不可避免，但我们有确定的沟通机制和处理流程来帮助大家解决问题。
预警和冲突解决机制建设
根据这四个挑战，架构师需要完成的任务项依次是
作为架构师，我们可以从技术视角解决前四个挑战。
而后两个挑战，则要依靠项目经理来推动完成。
六个其他方面的挑战
项目启动前的准备工作
我建议你可以邀请高层决策者和赞助者来分享项目背后的思考和动机
项目启动完成
29｜节点五：项目启动仅仅是一个仪式吗？
指的是从架构活动中分离出最小的、有增量价值的交付单元。
从用户视角看，这个单元可以被单独识别。
1. 独立性
从阶段性交付的商业价值的角度看，我们从这个单元得出的结论是完整。
比如这么做的价值足够大吗？对于这个问题，我们得到的答案必须为“是”或“否”，而不能是“很难说”这种模棱两可或欲言又止的回答
2. 结论的完整性
这个单元为目标用户创造的价值可以被数字化、被度量
3. 可度量性
具备如下三个性质：
最小价值单元（Minimal ValueProposition Unit）
而阶段性价值交付的目的，就是让决策者及早看架构活动的真实价值
此外，这么做的意义还在于，确保我们架构师把注意力放在交付的增值上，而不是交付功能或者交付代码上。
在价值单元交付的过程中，要在保障结论有效性的前提下，尽早把一个完整的功能发布给目标用户，同时向他们及时收集反馈
我们的目标是把问题尽早提给市场，让市场给我们指点迷津，而不是凭空猜测。
一是帮助团队将目标锁定在正确的目标上，避免偏离
二是验证预期增值是否满足期望。
收集反馈主要有两个目的
这个过程的王道是忠于架构目标，尊重市场反馈，以最大化企业 ROI 的原则，选择正确的交付路径。
为什么要做阶段性的价值交付？
从目标用户的视角看，最小可用的价值单元是什么？
用户是如何感知到这个功能的价值的？
阶段性 MVPU：
用什么量化指标来度量这个功能的价值？
如何通过 A/B 测试来验证这部分的价值？
要知道，做拆分的主要目的就是尽早拿到一个结论性的量化评估。
阶段性目标
在不破坏项目结构的前提下，交付 MVPU 的强依赖是什么？
这是我们架构师必须给出的答案。
当然，强依赖可能包括一些非技术的依赖，比如招募参与前期实验的商家、营销费用和培训内部运营人员等。
最短路径
进入阶段性交付前的准备工作
30｜节点六：如何保障高质量的阶段性交付
这个项目能为企业带来哪些重要的商业价值呢？
比如一个大促项目，比较重要的指标有 GMV
总订单数
总成交客
度量这个商业价值的核心指标是什么？
首先是商业价值的视角。
这个项目能为用户带来什么重要的价值呢？
常规的度量用户价值的指标有新买家数、
买家满意度
成交用户总数等。
相应的指标是什么？
其次是用户价值的视角。
这个项目能为企业带来哪些重要的技术价值？相应的指标是什么？
同样还是大促的例子。每秒峰值订单数、机器人会话转人功率、大促会场转化率等，都是对企业技术能力的度量
在真正的竞争压力面前，这种 ROI 最大化的路径，是我经历过的最有效的项目推进方法。
最后是技术价值的视角。
从价值交付的角度做 MVPU 拆分
架构师的价值就在于保障整个架构活动的结构性，以及交付顺序的合理性。
前提
1 是整个架构活动的目标，a、b、c 是三个 MVPU，它们各自依赖的交付任务由带箭头的线来表示。
比如对于 MVPU a 来说，任务 2 是它的强依赖，而任务 3 是它的弱依赖。
其中 c 节点与整个架构活动的目标无关，它只是附属在架构活动上的一个“小确幸”，不应该作为 MVPU 的选择
如果说一个节点始终没有通向节点 1 的路径，那么这些节点可以看作技术的自嗨任务，应该砍掉，或者作为低优先级任务。
一个 MVPU 是一个树状结构，比较容易计算总交付成本和交付时长
1. 梳理强依赖关系；
因为大项目的联调成本很高，交付过于频繁会打乱研发节奏。
但是如果超过一个月还没有交付任何的 MVPU，积攒的风险就会变得很高。
周到一个月之间。
最后是把握速度和结构性的平衡。
交付路径设计
在交付的过程中，你还需要跟踪每个任务的进度，把实际观察到的结果跟 MVPU 的目标反复做校准
交付跟踪与路径调整
完成阶段性交付
31 ｜节点六: 如何组织阶段性的价值交付？
寻找可以提升未来架构活动成功概率的机会。
其中，E 指的是公司未来某个架构活动，A 指的是复盘分析
这个定义的意思就是，通过复盘分析，公司未来的架构活动的成功概率必然能得到提升。
我们可以用一个公式来表示，也就是 P(E) < P(E|A)
复盘的目的
复盘的对象不仅包括失败案例，还包含成功案例
我们通常对成功案例有着较为主动的学习动机，也就是我们经常提到的路径依赖
而对于失败案例，我们却常常有着自我治愈和选择性遗忘的倾向。
其次是复盘的对象
谁造成了我的失败
复盘可以有多个视角：一种是对他人的审视
我什么地方做得不完美
一种是对自我的审视
还有一种是上帝的视角
最后是复盘的视角
假设一家公司的研发人员压力大、交付周期短，自动化测试覆盖率也不够高，导致项目发布经常带有故障
如果这家公司在灰度发布、指标监控和自动化回滚等方面做到了极致，那么即便有故障，但靠着发现及时、报警响应快、能做到一键回滚，也能保障项目发布的稳定性
在一个重大问题出现后，很多公司的做法都是先在公司内部找到第一责任人，然后对责任人处以与失败相同量级的处罚，甚至开除。
这种机制的目的是防止复盘参与者互相包庇，最后大事化小、小事化了。
不好的地方
问责机制的确可以用在复盘环节中，来帮助公司发现问题的真正根因。
不过也要明白，找到或惩罚责任人并不是复盘的目标，也不应该是复盘的终点
复盘的目标是寻找可以提升未来架构活动成功概率的机会点。
主要
第一个最常见的误区是止于问责。
在复盘的过程中，肯定会涉及到自我剖析，让参与者寻找各自的提升点
但是项目复盘，更重要的是整个公司的能力提升，而不是参与者个人能力的提升。
第二个常见的误区就是止于意识提升。
。更准确地说，就是止于损失回捞，也就是在最大程度上挽回问题所造成的损失
第三个误区是止于错误补救。
复盘的王道就是通过对失败事件的深度剖析，从中寻找一些机会点，从而提升企业未来的架构活动的成功概率。
复盘的三大误区
也就是平衡对他人的审视和对自我的审视
对他人审视和对自我审视其实是一对矛盾，当我们在一个视角上的思考做到极致后，难免忽略另一个视角
第一层是视角的平衡
同样，这么做也是为了把决策层面和执行层面的问题分开来看，寻找各自的机会。
第二层是平衡公司内部不同的决策层。
技术人员做复盘的时候，话题往往是如何改变设计、如何完善监控发现工具、如何提升工程效率，以及如何提升数字化决策的质量
从公司层面看，通过其他手段也可以达到同样的目标，技术手段只是其中一种。
因而在复盘中，需要引导参与者注意平衡思考的维度。
第三层是平衡不同的维度。
很多人做复盘，还没完成全面分析呢，就已经列出了一大串行动点，准备整治了。
复盘不是故障响应，不需要立即止血。复盘的重点在于追寻问题本质，而不是整治现象。
第四层是平衡思考深度和行动时间。
为参与者提供一个安全且平衡的复盘环境。
1. 建设复盘氛围：
从公司层面的宏观视角看，错失的最可惜的机会点是什么？
梳理错失的机会点：
引导参会者对复盘目标有个清晰的认知
如果不能拿到一个非常有洞察的、能真正提升未来成功概率的结论和行动点，那么复盘就不能结束。
设定目标：
进入复盘前的准备工作
32｜节点七：什么是有价值的复盘？
包括主要决策的环境
最终的决策
以及由此推演而来的规划
是以时间顺序对事实进行多维度的客观描述
如果你能提供充分的视角，并为每个视角分配合理的权重，将会大幅拓宽机会洞察的搜索半径，找到更高质量的提升点
1. 回顾架构活动；
复盘的一个重要原则是保持平衡的视角。
首先要邀请一组具备不同视角的参与者来参加复盘。
不能清一色地邀请研发人员，因为研发人员往往只会从技术视角出发来做深度探讨。
1. 从公司视角出发，而不是从个人视角出发。
2. 提供“我可以做什么”的视角，而不是“他可以做什么”的视角。
3.提供彼时彼岸的视角，而不是此次此岸的视角。什么意思呢？我们在复盘时不要乘着时光机乱飞，不要把未来的知识带到过去中
4.提供找机会的视角，而不是追责任的视角
从目标设定到架构环境搭建，再到最终的交付，有什么可以改进或提升的地方？
1.整体流程
公司在大型决策中的质量怎么样？如何进一步提升决策质量？
2.决策质量
我们到底有没有真正意义上的架构规划？这个架构规划有无重大缺陷？
取舍是否正确？架构规划对实施起到指导作用了吗？
3.架构规划
实施过程是否忠于最初的目标？最终是否能交付预期的价值？
4.执行和实施
核心模块的最终质量是否达到了预期？
5.质量控制
团队是否胜任？组织是否给力？协同是否高效？
6.组织维度
公司文化对架构活动的成功有帮助吗？还是阻碍了架构活动过程中的探索和求真？
7.文化维度
重点关注几个维度
2. 搭建复盘环境；
你需要引导每个参与者共同思考一个问题：在可控维度上错失的最大机会点是什么？
1. 在某个维度或者某个组合维度上，我们错失的最大机会点是什么？
2. 这个错失的机会点有多大？可以从商业价值或者用户价值上来度量吗？
这个过程是个多轮的共创过程，每个参与者都要思考如下几个问题：
3. 梳理机会点；
为什么你没有事先意识到问题？比如通过某种形式的监控而提前发现问题呢？
但是为啥你没意识到呢？
你没想到，是因为没有时间，还是说给了足够的时间也想不到呢？再遇到这样的问题，你还是会想不到吗？
为什么呢？
为啥是单点呢？
为什么是强依赖呢？
我们的假设正确吗？我们的商业模式就应该是这样吗？我们流程就应该是这样吗？
五个why
4. 挖掘根因；
默认当前的做法就是正确的做法，当前的模式就是正确的模式，当前的流程就是正确的流程
但是很多时候，我们都被自己过去的错误所框住了
一旦突破这些束缚，就能提升未来架构活动的成功概率了。
所以作为架构师，一定要把个例中的发现转变成一种模式和企业的机制。
在这整个过程中，你的目标是尽量找到一个模式和机制，而不是解决一个单点问题
只有前者，才会持续提升整个公司的成功概率。这就是我们反复强调的复盘的终极目标
5. 寻找新的模式与机制；
因此，只有集中精力认真分析少数几个跟进项，才能有效提升这些跟进项的存活率。
最多保留三个跟进项。
产出跟进项
复盘过程一般由如下六个环节组成
复盘就是从公司层面进行回顾过程、搭建环境、梳理机会点、挖掘根因、寻找新的模式与机制、产出跟进项的完整过程
完成复盘
33｜怎么样做好一个有长期收获的复盘？
架构师的作用贯穿架构活动的整个过程，是架构活动的设计者、规划者和执行保障者
通过持续发掘和评估重大风险，来控制整体的交付风险
通过分析和解决差异点，促进尽可能多的参与者达成共识
通过不断分解问题，保障增量价值的交付
通过持续的文档沉淀，从而驱动科学的决策
底部的绿色条，来表示架构师在架构活动中持续创造的价值
绿色部分
我用黑色直角线条连接了节点一与其他六个节点，来表示这种父子关系
节点一产生了能覆盖其余六个节点的大环境，也意味着节点一与其余六个节点形成了父子关系。
一个大环境
项目上线
总结复盘
浅蓝色来表示八个大节点
一个是在目标确认环节
一个是在项目上线环节。
图中有两个圆环形图标代表了“目标确认点”，就是完成架构活动目标确认和验证的时间点
两个圆环形图标
入口一是风险决策的时候，指的是发现无法控制的重大风险。
入口二是架构规划确认的时候，指的是发现架构规划无法满足预期目标。
入口三是规划正式确认的时候，指的是发现执行计划存在重大风险，无法满足预期目标。
代表执行放弃的动作。每个放弃的动作都有三个入口，也就是三个放弃点：
放弃得越早，风险越小，成本也越低。放弃得越晚，团队承担的心理压力越大，对团队的士气打击也越大。
图中还有两个深红色的三角图标
同时，需求侧的角色也对项目成败有着重要影响，比如产品经理、产品业务运营等。此外
在有多个复杂汇报关系长期参与的情况下，HR 也是一个非常重要的角色。
其他
这里需要注意的是视角的不同。我们整个模块是从架构师的视角出发，来描述我们在架构活动中的关键动作和行为
如果换个视角，比如把架构师换成决策者，那么他的关注点、行动点和思考方式又有所不同。
标记在图中的四个人。
这张图里还绘制了一些反馈链路，比如蓝色线条，始于节点六（阶段性价值交付），终于决策者，
代表在阶段交付的过程中，架构师必须向决策者反馈交付进度和重大风险之类的信息。
这里要强调的是，架构活动成功的关键，就是为整个架构活动设置多个反馈链路，确保自上而下和自下而上的反馈链路都是通畅的
有了这些反馈链路，我们才能掌握架构活动的真实进展，在出现问题时能及时干预，避免问题失控
蓝色线条
四个核心角色
架构活动总览
34｜模块小结：架构师如何在架构活动中持续创造价值
软件架构师指的是具备软件架构能力的人，或者是以这种能力谋生的人
而所谓的软件架构能力，就是为相对复杂的场景设计并引导一个或多个研发团队，来实施结构化软件系统的能力。
模块一是讲架构工作中要遵守的原则
模块二是讲“为复杂场景设计和实施结构化的软件系统”的具体工作方法
模块三是讲做好架构工作所必需的能力项
模块四，则是讲这些能力维度背后的本质能力，即思考力。
定义分析
同时，这五个能力维度又是互相正交的。哪怕你在某个能力维度上做到了极致，也不等于自动获取了另一种能力。
架构师的能力维度
35｜模块导读：回过头来看，你觉得架构师到底是做什么的？
软件架构能力指的是为相对复杂的场景定义并引导实施结构化软件方案的能力，其中结构化
代表这个软件在其设计范围内的设计理念、代码结构和实现方式上是同质的。
这种追求，在一个程序员的职业发展中是具有连贯作用的
从程序员到 CTO，刚开始可能是对代码结构性的追求
随着职业的发展，这种结构性会扩展到更大的范围和更广的维度中，甚至延伸到公司软件研发的各个方面
最终，代码洁癖就会演变成对于软件系统甚至研发组织结构性的执着，而这种执着也会固化成对软件结构性的识别、改进和设计能力，贯穿整个职业生涯。
可以说，对于一个以架构师为职业追求方向的程序员，结构化设计能力是基础能力
洁主要来自编程规范的掌握和运用、设计抽象和常见设计模式的采用。
代码整洁
而你出手就不一样了，是一个基于对问题本质、商业价值和软件结构性思考的长远设计！
用一句话来简单描述就是：如果遇到这种场景，就应该采用这种设计模式。
这是个系统化且高效借鉴他人成功经验的过程。
一是沉淀经验
也就是对代码背后思考的一种标准化注释。
二是传递设计原理
在设计模式的基础之上，一旦开始模块设计，就需要对世界做建模
这时候还需要学习问题域建模，也就是通过领域模型帮助我们与所有需求方在某个问题上达成共识
也就是如何以简洁明了的方式包装要解决的问题，让使用者能够轻松且长期使用你的服务
而不需要耗费大量的时间去理解、学习、集成、测试、维护和升级系统。
确定了问题之后，接下来就可以设计服务 API 了
另一个对代码整洁性帮助很大的就是设计模式。
如何提升结构化设计能力？
整体设计需要与公司或部门的理念保持一致。
比如整个公司都采用分层架构，那么你的设计也要尽量采用分层架构
整个公司都采用微服务的设计理念，那么你的设计也要采用微服务的设计理念
否则写出来的代码既难维护又难理解，也难以被别人复用。
第一，设计理念。
也就是说，软件模块的对外界面要有比较明显的语义结构。
暴露给其他调用方的 API，要有条理、表达准确，且易于理解
否则，API 在被使用的环境中，会让调用方的代码变得晦涩难懂、结构混乱
因为这些状态和行为会随着实体的生命周期而发生变化，所以 API 就要围绕实体生命周期来组织。
而围绕一个流程定义的API，则要根据流程的前后顺序来组织 API
甚至在 API 命名上的语言结构性，也会大幅提升 API 的可读性和可维护性。
要反映出这个实体状态和行为
举个例子，一个 API 可能为多个用户角色服务，每个用户角色又有多个场景，每个场景还可能有多个功能
角色、
场景
功能
那么这些功能就应该组织成三层的结构
不同的用户角色和不同的使用场景，都应该有不同的设计粒度。
其次是功能组织上的结构性
API 会暴露数据给调用方，那么暴露出来的数据就要有清晰的结构，遵守一定的规范。
假设你在使用 JSON 传递数据，那么 JSON 就要做到可读且合理。
所谓可读，就是只看JSON，很快就能明白这些数据的含义，及其内部对象之间的关系
所谓合理，就是包含在JSON 中的数据结构符合最小必要的原则。
最后是数据模型的结构性
API 的结构性体现在三个方面
第二，API 的结构性。
也就是程序的结构性。这种结构性其实是我们前面提到的程序员设计能力的具体体现。
第三，模块内部的结构性
结构化设计过程中的具体关注点
36｜能力维度一：如何提升结构化设计的能力？
指的是能够结构化地完成业务需求的一线软件工程师。
程序员
除了需要关注自己的代码外，还要关注横向问题。
兼职架构师
从程序员到兼职架构师
性能
可扩展性
可用性
可测试性
可维护性
安全合规等问题
简单来说就是软件系统内部与业务无关的技术债
这些问题都属于非功能性需求，也就是说，产品经理一般不会把这些问题直接写在需求文档里
1. 你与周围同事在横向问题领域内有认知盲区；
2. 由于日常研发过程中的优先级取舍，导致一些技术债被短期搁置。
技术债产生一般有两个原因
横向问题的解释
首要任务，一定是先把日常的研发工作做好。
如果有额外的精力，我应该先花费精力提升本职工作的深度，还是分出一部分精力去提升解决横向问题的能力呢
从哪里开始？
如果没有足够的兴趣，这个过程肯定是不那么愉快的，也很难坚持下来。
首先是个人兴趣。
也就是说，解决这个横向问题能给公司带来多大的价值？
给公司带来的价值越大，未来你获得的机会回报也就越大
甚至，公司还愿意花钱来加速你的能力提升。
其次，要考虑商业价值。
从三个方面考虑
如何跨越从程序员到兼职架构师的障碍？
如果现在还没有特别感兴趣的方向，公司内部的机会也差不多，只是单纯想找一个领域先提升自己
在这种情况下，我建议从稳定性开始。
企业既然花钱投入了软件研发，最终肯定要做一个稳定的软件。
首先，稳定性是任何一个企业都绕不开的问题，是第一性的
如果你写的代码和服务更稳定可靠，就不用半夜从床上爬起来去接报警，活得也更轻松一些
这样才有机会脱离工作的高压，去研究一些更有深度的问题。
其次，做稳定性会先让自身受益。
最后，稳定性问题和程序员日常代码工作的连续性比较大，你可以一边提交日常需求，一边做稳定性相关的改造
你依赖的服务，不会返回他们应该返回的东西。写代码检查依赖，远比 Debug 代码容易得多
永远不要轻信（别人的话）！
代码可靠的原因在于，从来都不要相信自己的代码是在一个可靠的环境中运行
认知
1. Trust none！
来自系统工程学科中的一个结论，也就是系统的可用性会随着复杂度的提升而降低。
如果想设计一个高可用系统，就必须把依赖最小化。
第一，如果是被迫引入依赖的话，就要选择最靠谱的人和最靠谱的模块
第二，从管理者的角度来看，在故障出现之前就要锁定那些能真正保护好系统，并且能给出正确判断和方向的人
引申的两个结论
2. Only rely on the most reliable.
所有东西都会过期变质，尤其是数据。
你拿到的数据、配置、服务、消息通知等都可能过期。你给别人的数据也是一样的
这些数据可能在过去某个时间点是有效的，但绝对不是现在。
在分布式的世界里，那些简单回滚解决不了的生产环境问题，往往是因为数据配置和频繁更新的代码不匹配而造成的
对于这部分问题，需要把线上系统和可能已经被污染的数据尽量隔开，快速止血。
这其实是个设计原则，也就是在设计中要考虑数据污染的情形。
如果有多个选择的情况下，应该选择范围更小、可靠性更高的数据来源。
在生存（也就是维持系统可用性）面前， 所有依赖都可以被降级。
通过大量的压测和充足的预案，确保一个超高赌注事件能 100% 成功
不考虑成本的稳定性就是耍流氓。
在中小企业，做稳定性必须要控制成本，而不能因为追求稳定性而牺牲迭代的速度或者大量的现金
5. Availability without cost consideration is bullshit.
猪队友永远在你最危急的关头出现，关键时刻要有能力保护自己！
6. Save yourself!
为什么要从稳定性开始？
37｜能力维度二：如何提升解决横向问题的能力
一个业务中（也就是一个大公司的 BU，或者是一个小公司）有多个产品线，每条产品线都有各自对应的产品经理。
一个产品经理，又往往对应着一个或多个研发经理
一般来说，每个研发经理在负责一个研发领域的同时，还会带领一个团队
团队中有多名程序员，每个程序员各自负责一个或多个软件模块。
跨域架构师和研发领域是一对多的关系
程序员和研发经理，则和研发领域形成一对一的关系
如果程序员和研发经理同时具备兼职架构师身份的话，这名兼职架构师就和研发领域形成了一对一的关系
跨域架构师和研发经理形成了一对多的关系
因而这张图表明，从兼职架构师成为跨域架构师，需要完成从一对一关系到一对多关系的跨越。
比如性能、安全、可维护性之类的问题
如果发现问题，自己动手解决即可，不需要化解多个团队之间的冲突。
这个角色只需要关注自己领域或模块的架构问题就行了，解决的还是内部技术债的问题
跨域架构师的价值在于解决一个复杂组织中必然存在的局部与整体的冲突，最终要从全局层面寻找到最优解。
跨域架构师
跨域架构师和兼职架构师这两个角色在概念上的差异
要持续抵抗天然的熵增，将多个子领域中不同的设计理念、代码结构和实现方式，往同质的方向上进行整合。
跨域架构师的核心挑战
干预前
干预后
跨域架构师的存在就是协调子域之间的决策、执行和沟通，从而平衡全局结构化和局部个性化之间的冲突，最终最大化全局目标的实现
必要的时候要靠真实可靠的技术论据和完美的逻辑来说服大家采用正确的判断。
理解整个全局领域的目标。
最大程度地熟悉每个子领域，理解每个子领域的目标、挑战和需求的差异性。
围绕统一的目标去分析局部视角上的差异性，引导各个决策者和执行团队从全局视角上看问题，最终引导多个子域在目标和全局目标上形成对齐
设计公开的沟通机制，促进子域之间的信息对称，使得每个决策者和执行者能够看到全局的优化目标，以及其他团队的重大决策、执行方式和当前状态
逐步解决具体的设计理念、代码结构实现方式的冲突，达到全局最优
跨域架构师该如何突破局部视角的障碍了：
38｜能力维度二：如何提升解决跨领域冲突的能力
在处理整体和局部冲突这件事情上，总架构师就是在执行跨域架构师的角色，从公司层面解决技术架构上整体和局部的冲突问题。
也就是说，技术架构是否正确，有诸多考虑因素
既有对技术未来的判断，也有对人才供给的判断，还有对公司内外部环境的判断
这里没有对错，只有对长期趋势、风险和收益的估计，是个需要拍板的过程。
从跨域架构师成长到总架构师，必须要跨越不确定性的障碍。
：在软件架构这个上下文里， 总架构师指的是当面对技术发展的不确定性时，能对未来有个清晰且正确判断的软件架构师。
总架构师的核心能力：做正确的技术决策
理解整个决策的背景。
理解决策的制约因素。
在你所精通的领域提供尽可能多的依据，在最大程度上降低小决策的不确定性。
从你所精通的领域出发，为最终决策做出建议（也就是拍个板）。
尽可能多的参与到决策讨论中，了解其他领域的不确定性和收敛方法。
无论最终决策是否与你的建议一致，都要尽可能地理解最终决策背后的逻辑。
之后的数月甚至是数年，持续关注决策的后续进展，反思自己提供的决策建议中那些缺失和误判的部分
哪怕决策是对的，那么其中有多少成分是靠运气呢？有多少成分来自对当前环境和未来趋势正确的判读
如果判断错了，那么其中有多少是假设错了，有多少是方法错了。
之后的数月甚至是数年，关注其他领域后续的变化，思考最终决策的正确性。注意，不仅要看最终效果，还要看判断决策逻辑和过程的对错
帮助他人做高风险决策时，要做的事情就是
成长到总架构师需要跨越的障碍
除了 CTO 这个位置之外，所有的技术职能，包括总架构师，都是以企业技术实力的增长为第一优先级的
但 CTO 不是，企业的长期生存才是他决策的第一优先级。
从长期的技术发展角度看，云原生会带来更好的计算伸缩性、更大的技术生态、更先进和更快速迭代的技术栈。 那么公司应该把线下的机器迁移到云原生上，才能加速在云原生技术栈上的积累。而且要立即规划和行动，才能尽早培养人才和积累技术优势
做迁移会增加技术投入，降低业务迭代速度。
云原生迁移带来的回报，是个长期且相对缓慢的释放过程。在迁移前期，由于周边技术的不成熟、投入大，资本回报反倒比较小。
最重要的一点，迁移到云原生并不能给企业带来当下的生存优势。而长期的生存优势，跟云原生并不是能简单证明的关系。
但是从一个 CEO 的视角来看：
作为 CTO，需要站在 CEO 的角度上思考技术问题
技术先进性并不是首要目标，必须从竞争视角出发，以公司的生存和长期成长为目标来做技术取舍
在这个视角下，投入技术创新、加速技术壁垒的建设、放弃某项先进技术和某个团队，甚至寻找技术之外的选项，断臂求生，都是非常合理的选择。
在软件架构这个话题上，CTO 视角的独特性在于技术不是第一优先级，也不是唯一的选项
这种以商业视角而不是技术视角思考的方式，就是你必须跨越的障碍。
某个 CTO 管理一个跨国业务。有一天，他的团队同学告诉他：“我们收到法务部门通知，某某国家发布了数据合规法令
依照合规要求，我们需要在这个国家建数据中心。投入是 500 人日，外加 450 万美金的建设成本，以及其他为数不详的维护成本。这个项目非常复杂，需要马上启动。”
CTO 听到汇报后，没有批准任何技术预研，而是请政府关系（GR）部门联系了当地的监管机构和律师事务所，寻找不建设机房之外的其他选择
GR 各种操作之后，机房不用建设了。不但省下了各种成本，也避免了系统复杂度的大幅提升。
解决方式
这种在技术之外寻找解决办法的思维，是一个 CTO 所必需的。
成长到 CTO 要跨越的障碍
总架构师和 CTO，我的双重人格
39｜能力维度三&四：如何从做技术到为企业创造生存优势？
不过无论做什么事情，都必须先问自己这么一个问题：我做这件事情的优势是什么？也就是说，我凭什么可以成长为比别人更优秀的架构师？
一个是成长为优秀架构师的必要条件
另一个是成长为优秀架构师的充分条件。
其实这个问题背后隐含着两方面的诉求
主要关注需求实现的结构化，也就是一个模块内有关业务的部分
在程序员阶段
主要关注模块整体，以及与业务无关的横向问题。
兼职架构师阶段
主要关注不同模块间结构合理性的问题。
跨域架构师阶段
总架构师阶段
关注企业的长期生存。
CTO 阶段
任何一个架构师，都要关注从宏观到微观的所有问题，只不过权重有所差异罢了
代表架构师成长的五种角色
如果说架构师成长的必要条件只有一个的话，我认为只能是思考力。
重要性
思考力是在我们生活和工作中，通过独立思考带来有效结论的能力。
独立，并不是避免跟别人讨论，或者是不上网查资料、不参加会议
有别于其他人的视角；
不同的证据组合；
不同的思维方式。
主要来自如下三个方面
也就是说，通过你的独立思考，能得出区别于他人的结论。
首先是独立思考。
简单来说，就是你看到了别人看不到的东西，并且这些东西对于公司来说是有价值的
而不是把大家的注意力分散到了没有价值的方向上。
其次是“有效”，也就是为公司或团队带来足够的价值
概念剖析
其实这两个能力完全不同，后者指的是把已有的知识高效吸收和利用的能力
好的学习能力会帮助你获取更多维度的证据。
而思考力是创新的源泉，是得到新的有效结论的能力
思考力和学习能力的区别
必要条件之一：思考力
在架构职能上做得比较好的人，一般都具备一定程度的信息优势，以及高效内化这种优势的能力。
所谓信息优势，就是你所在的环境有大量高质量的信息，或者你获取这些信息的能力比别人强，渠道比别人多。
所谓内化
这里我特别用信息，特指独立于客观存在的那些内容
用知识，指我们脑海中可以随时随用的那些内容。
信息和知识
信息内化的过程，也就是从接触信息到消化吸收成个人知识的过程
如果能更进一步把这些知识系统性地表达出来，你就是一个很了不起的知识传播者了。
这个过程，会帮助你把外部的信息优势内化成内在的知识优势
当处在一个有相对信息优势的环境中，你又比别人更擅长发现、总结和抽象知识，最终就会形成知识优势。
所以架构师成长的一个必要能力就是适应能力 （Adaptivity）
在不同的成长阶段，根据环境和场景不断调整和扩大自身的能力维度，目标是最大化自己的产出，以及对企业的增值
第一组技能是靠时间、经验和机会磨练出来的，不能仅仅靠读书学习来提升
从程序员到 CTO，所处理问题的不确定性越来越高
而在应对不确定性的过程中，业务理解能力也变得越来越重要。更大的领域范围，也要求更大的技术宽度和更好的沟通交流的能力。
第一组是伴随职责而扩大的岗位技能；
是可学习的，往往学校里的优等生会比较出色，但是随着架构师职责的扩大，对技术深度、项目推动交付的能力和执行细节的关注，就会越来越少
所以这组技能对于职业初期的成长来说很重要，随着时间的推移，慢慢地就没那么关键了。
第二组是个人技能；
一般来说，架构师这个角色没有下属，少数的首席架构师会带小团队，对管理能力的要求不高
但是 CTO 的管理幅宽非常大，往往会突破 Dunbar Number，也就是社会学家认为的一个人能够有效管理团队的大小。
也正是因为这个原因，一个优秀的个人贡献者，在成为管理者的过程中往往会栽很多跟头。
请注意，不是社交能力，而是基于自身经验和管理科学的管理能力
第三组是管理技能。
第四组，就是我们前面几节课提过的每个角色的工作范围、工作重点和核心能力，这里就不重复解释了。
分为四组
必要条件之三：适应力
想培养出这五个维度的能力，需要具备什么必要条件呢？
40｜职业成长：架构师成长的必要条件是什么？
架构师的成长，就是在更大的领域范围、更高的难度和更大的不确定性下做决策的过程。
比如说程序员，就是在代码层面做结构化的决策。
兼职架构师，就是在一个领域内做横向问题的架构决策
跨域架构师，就是面对复杂的团队冲突，在多个领域间做全局最优的架构决策。
总架构师，就是面对技术发展的不确定性，从公司层面出发，顶住来自业务方的压力，作出长期最优的架构决策
CTO，就是面对竞争环境的高度不确定性，从贵公司层面出发，面对成本压力和团队内部压力，作出最利于企业长期生存的技术决策
不同的角色
大量高风险的决策机会；
公司高层在讨论核心业务的规划时，要邀请架构师参与，让他们提前知道公司面临的挑战和即将到来的模式转型
不是在公司完成最终决策之后，通知架构师第二天就要给出设计方案
相对宽裕的决策时间
就是让架构师和技术团队作为决策的参与者，并在决策过程中充分尊重他们的判断。不要每天拿“既要也要还要”来说事儿
对架构师意见的尊重
任何高风险的决策，必然有错误的可能性存在。
但是有些公司非常惧怕风险，会通过各种惩罚性措施来防止意外事件的发生，而且还配置有严格的追责流程
对错误决策有足够的包容度
什么样的环境
对架构师友善的环境；
比如顶层决策者能力不足，没有看对方向
中层决策者由于自私，而将目标转移到最大化自己团队利益的方向上
一线管理者因为信息缺失导致判断失误，等等。
目标设错的原因
其实这种目标管理的环境也不难鉴别。这样的目标在定义中就公开透明，鼓励全员参与；
在决策中尊重数据和事实输入，有确定的 KPI 和数据结果来衡量产出
在最终的复盘中，不忌讳失败，会认真反思分析。
正确的目标
41｜职业成长：架构师成长的充分条件是什么？
企业的成长周期
从上图可以看出来，当一个新的技术或商业模式被发现后，会有大量企业涌入，整个行业进入创新期。
后行业进入成长期，但是参赛者会被大量洗牌，仅有几个企业能活到变现期
国内移动互联网的几个大战，像千团大战、打车大战、共享单车、社区团购，都符合这个规律
拉长时间看，国内外的家用电器行业、PC、手机、智能手机、互联网门户、搜索、电商、物流，也完全符合这个趋势。
描述了在不同生命周期状态下相应的高科技企业数量
红色实线代表一个企业的员工数。一般来说，企业在变现期的顶峰时，员工人数往往最多，之后就会逐渐减少
蓝色虚线则代表企业内部的人才成长机会。在企业的初创期和高速发展期，充满了机会
而这些机会，在成长期的顶峰达到峰值，在变现期之前开始下滑。到了衰老期，机会将变成负数。
色实线表示机会密度，它等于机会数量除以员工数量。在初创期和成长期，企业人数少，所以机会密度一直维持在较高水平。机会密度的峰值出现在成长期的峰值之前，在这之后就会急速下滑。
从企业成长周期来思考职业选择
42｜职业选择： 我应该去哪种类型的公司工作？
是软件结构性的最小起点，指的是每个程序员提交的代码在设计上的一致性
代码是所有上层软件结构性的最终载体，也是现实世界中所有结构化决策，最终具象化到软件世界中的呈现方式
这种一致性的主要价值，在于代码的可维护性，以及代码易于变更、升级迭代和扩展的性质。
首先是程序员 / 代码的结构性
这是第一层抽象，也就是在多个代码模块中间共享同一个横向问题的解决方案，让横向问题的解决方案在多个模块中是一致的
这种一致性往往来自一个简单的组织抽象，也就是在多个代码模块中共享同一个有解决横向问题的兼职架构师。
这种一致性的价值，就在于更低的实施成本和更高质量的解决方案。
然后是兼职架构师 / 横向问题的解决方案
这是第二层抽象，指的是在多个领域之间维持整个解决方案的结构性
这种结构性体现了设计理念、数据模型、信息交互的一致性，最终将促进整个领域的结构性
这种结构性的价值，就在于让整个领域的软件质量更高、可维护性更好、更容易升级迭代。
接着是跨域架构师 / 整体的解决方案
这是第三层抽象，指的是在软件架构相关投入上的决策原则，在整个企业内具有一致性
也就是说，总架构师的存在是为了保障企业在不同层次、不同领域上的软件投入的决策原则是同质的
这个决策原则，就是最大化技术的长期增值。
接下来是总架构师 / 决策原则
这是最高层次的抽象，指的是理念上的一致性
我们在课程中提到了，从 CTO 的视角看，企业在决策理念上应该和 CEO 视角保持一致，也就是最大化企业的生存。
在这个理念之下，企业的资源投入，不论是在技术、运营，还是市场，都应该和最大化生存这个目标保持一致
技术这个职能没有特殊性，仅仅是其中一个手段。
最后是 CTO／企业生存优先的理念
什么是结构性？
在一个新的角色上要解决什么问题？
为什么这些问题需要开发一个新的能力维度？
就是要先看清楚目标
现有能力为什么不满足这个新的目标？
然后我们再分析：
成长出这个新能力维度，所需要跨越的障碍是什么？
最后再分析：
我们整个模块内容都遵循着一个表述模式
分析过程如图所示
能力成长的关键，在于发现和跨越障碍
还有其他的必要和充分条件吗？
模块小结：什么是架构师成长的关键能力？
https://www.zadmei.com/mkddjrwz.html
独立思考
模块导读：假如我只能要一个技能
指的是当我们面临一个问题或一组选择时，所采取的固定的前提假设和思考路径。
思维定势
指的是某种特定的思考过程，它是一种具体的思考方法
思维模型
这个定义就可以看出来，思维模型是思维定势的一个重要组成部分。
关系
思维定势与思维模型
从模块一的生存法则开始
到模块二对架构活动的规划和干预
再到模块三的架构师的能力维度，我们一直在总结架构师必须要创造的价值，以及创造这些价值的方法。
如果从价值创造这个视角出发来总结我们整个课程的内容
如果说有一个思维模型贯穿的话，即架构师的每一个决策信条和最终行动，都要最大化自己为企业创造的长期价值
我将其称为价值思维，在我看来，这是架构师思维模式的起点，也是这个职能存在的重要前提。
不过对于架构师这个职能而言，这个思维定势有一个约束条件，即我们在模块一的总结里提到的过程正义
为什么过程正义是一个必选而不是可选项呢？
因为架构师这个职能需要通过他人来间接地创造价值。
如果你作为中间人都不能维持过程正义，就别指望资源持有者和决策者能保证过程正义了。
架构师要面向组织、技术环境和商业环境的未来做最优设计
架构师应该是一个价值投资主义者，要尽可能地把软件架构设计和架构活动的重点，引导到未来 ROI 最大的方向上去。
观点一
架构师要有全局的理解和面向全局最优的决策原则，因此要对抗来自细分领域的短期行为和局部最优的决策。
观点二
架构师要通过提升软件系统的结构性，为公司创造更好的外部适应性，因此要对抗细分领域中因相对独立的研发决策而导致的熵增过程
观点三
我总结一下我们在之前三个模块里传递的主要观点：
过程正义的价值思维
模型是实证思维的一个重要组成部分，意思是对现实的近似和抽象
一个好的模型，可以帮助我们更透彻地理解影响现实的不同因素，发现并确认其中的本质规律
而从这些规律推导出的结论，则对实践起指导作用
模型解释
实证思维是一种通过对现实的建模和借助模型的思考，从而形成有价值的实践决策的思维方式。
实证思维和模型的关系
架构师的成长，从模型开始
架构原则、设计模式和思维定势都属于这一类，重点是这个理论是独立于实践而存在的，能够被单独抽象出来，而且被表述出来。
第一个特征，一个基于科学理论是可以被独立表述的
举个例子，在完备性上，我们的架构法则试图覆盖所有影响架构活动的核心因素，但是它们在自洽性上，其实缺乏论证
我也欢迎你指出这些法则中存在的自洽性问题来，一起改进。
第二个特征，这些理论是有一定的逻辑结构的，是完备和自洽的
通过这组公理和严格的逻辑推导，可以推导出其他的行为规律
公理越是简单，越是普适，规律本身的价值也越大。
第三个特征，这种理论可以被浓缩成一组公理
这跟“信则灵”的唯心主义思维有着非常大的区别。实证思维是科学思维，一个理论要公开地表达出来，接受不同时间地点、不同场景、不同使用者的检验，才能够逐步提升。
第四个特征，这些理论是普适的，是可以复现、迁移的，也是可以被比较和验证的
特征
实证主义
思维定势（上）：价值思维和实证思维
在左侧部分，使命、愿景和价值观用来引导企业的长期战略
同时，也可以由此制定出中短期的战略目标。而资金、各类资源和组织等方面的决策，则用来支持战略目标
这一切都是由企业的核心决策团队共同制定的，一般架构师不会参与到其中。
左半部分属于由企业决策者共同制定的战略
战略目标最终将转化为企业内部具体的活动（即图的右侧部分），这些活动多数是去中心化的，由企业内部员工来完成。
在这个过程中，架构师需要密切关注企业的战略目标和宏观决策，并将这些决策映射到去中心化的研发组织和计算机系统中去
因而在这个过程中，就需要架构师具备去中心化的思维。
右半部分则是企业日常经营的活动。
去中心化思维
去中心化不等于没有协调和沟通，也不等于没有中心化的过程。
第一，有效组织去中心化的思维活动。
去中心化思维不是让你放弃思考，而是要求你频繁切换思考角度，将自己放在各个分布式的节点上做换位思考
从而帮助其他人看到各自的思考漏洞，看清楚他与战略目标之间的差距
第二，保持频繁切换视角的思考方式
去中心化是对称性的，不能让架构师成为思考的单点（Single Point of Failure）
第三，相信“去中心化主义”
对于架构师而言，去中心化的思维主要包含三方面的含义。
在新的未知环境下，之前脑海里形成的架构模型就不再适用了，而需要在新的环境下对模型进行修正，也借此把你原有的架构模型的适配范围，扩大到新的环境中
这个过程，其实就是在完善实证思维能力，以及提升适应能力
四种思维模式的关系
贯穿职业生涯的成长思维
思维定势（下）：去中心化思维和成长思维
影响架构活动成败的要素有很多个。其中任何一个要素失败了，整个架构也就失败了。
比如目标设错会导致失败，技术选型错误会导致失败，资源匮乏会导致失败，不尊重研发人性会导致失败，等等
也就是说，整个架构活动的成功和每个要素的成功之间是“与”的关系。
架构师处在一个能够了解全局的角色上，所以需要把更多的注意力放在整体的目标上，以及把整个架构活动作为一体来创造的最终价值上。
第一，关注整体
也就是关注多种维度之间的平衡，而不能只关注单个维度
第二，关注平衡
每个执行领域内部的思考，应该由负责该领域的领导者完成
你可以检查他们内部的工作，但更重要的是关注跨领域的划分、领域之间的接口和跨领域的数据标准。
第三，关注链接，也就是关注领域之间的关系，而不是每个领域内部的细节
不过架构师的这种狭义的全方位思维模式还有以下的三个特殊性
架构活动初期：协同的全方位思维
我们需要不断审视过去所做的决策与规划，找出漏洞并快速修正
互联网企业很崇尚信仰驱动的文化，甚至整个执行团队都可以“但行好事，莫问前程”，但你这个架构师不可以！
p style=\
第一，理性思维，也就是拒绝一切非理性思维。
在一个架构活动中，我们的思考带宽和时间有限，所以要有选择地怀疑。而我们怀疑的内容，最终应该带来实用的知识。
所谓实用，就是这个知识会对我们的目标、架构规划和项目实施有所改变，最终也会对架构活动产生影响。
第二，价值导向
第三，首先怀疑。
那么对于我们架构师来说，应该如何使用批判思维呢
架构活动中：批判思维
架构活动中的思维模式（上）：协同式的全方位思维和批判思维
一旦进入执行阶段，我们就要在最大程度上保障用户价值的交付了。
那么在这个阶段我们要具备什么样的思维方式呢？
如果具体到软件架构的上下文里，实用主义思维指的就是以实际增值作为检验架构设计唯一标准的思维方式。
答案是实用主义思维（Pragmatism）
如果说你是一个信奉实用主义的架构师，那肯定会认为应该以实际的价值和最终的商业成败去理解模型和架构设计
执行阶段：实用主义思维
一提到复盘，你可能会马上联想到反思思维
反思是一个理性的思考过程，是基于逻辑思维的、理性的、怀疑的、公正的思维方式。
首先，反思是批判思维的一个具体应用。
反思首先是个自我批判的过程。我们前面提到的批判思维虽然也包含反思，但它的作用对象更多是一个客观的对象，也就是对架构规划进行批判
而反思，一般来说更关注的是自己，因此这是一个怀疑自己或团队的过程。
其次，反思过程的主要作用对象是你自己
在复盘过程思考的对象，就是你在架构活动中的思考过程本身
说得更直白一点，你在为过去的思考逻辑找 Bug：我到底因为何种思考方式的缺陷导致漏算了？
最后，反思的内容主要是自己的思考方式
第一，分解问题
响架构活动的因素太多了，多数时候，通过一次复盘得到的结论的有效性是存疑的。
因而最重要的是找到 2-3 个高价值的改进点，而不是找到几百个不一定有啥效果的跟进项目
这是个深度思考和发现的过程，不是把任务简单地分配给不同领域执行者的过程。
第二，发现重点
在复盘时，要在探索问题本质的过程中不断深入，发现抽象的、跨领域的、在更长周期中有效的不变量。
在这些不变量上做提升，从而带来更具普遍性的价值。
第三，追溯本质
那么在分析思维模式下，什么样的思考过程才能最大化复盘的价值呢？
复盘阶段：反思和分析思维
在目标确认、可行性探索和架构规划的过程中，我们需要在最大程度上使用全方位思维。这个使用的峰值发生在目标确认的环节上
第一个是较大的峰值，处在可行性探索的过程中。你需要通过批判思维来保证风险和预案的评估是否足够客观，而不是沦为形式。
第二个峰值是在总结复盘的过程，你需要通过批判思维来提升参与者的思考质量。
所以代表批判思维的使用程度的曲线有两个峰值
在可行性探索阶段和复盘阶段，我们都要使用批判思维
规划确认的后期、项目启动、阶段交付和全面上线的过程中，则主要采用实用主义思维。
而到了复盘阶段，则主要采用反思和分析思维方式。
这张图也表示了每种思维模式在每个节点上可以创造的价值。这些思维模式不是零或一的状态，而是在每个节点上都占有一定的比重。
架构活动中的思考方式
架构活动中的思维模式（下）：实用主义和反思思维
郭冬白的架构设计https://www.zadmei.com/jgxlkzlm.html
职业：暂无
0 条评论
回复 删除
下一页
