郭东白的架构课_33_23节点四架构规划之统一语义
你好，我是郭东白从。
这节课开始，我们就开始学习架构活动的第四个环节。
架构规划。
这个环节比较复杂，可以分成四个部分，也就是统一语义需求确认、边界划分和规划确认。
那么。
这节课我们先来讲，统一语义架构师的日常工作之一就是跟不同的角色沟通，那是每一个角色的认知和语言，都在各自的职能和工作环境中逐渐形成，并且固定了。
如果没有统一语义，那么整个架构活动就好像每人都做了一个梦，大家各自在自己的梦境中似乎玩的很开心，醒来后呢却满足没有任何改变。
想要架构活动最终能满足我们共同的预期。
那么先就要从统一语义来开始，我们整个架构规划。
我先来讲讲为什么要统一语义，听到了统一语义，你估计会产生这么一连串的疑问，这个过程到底是做什么的？那么么就要做挑战在哪里，怎怎么才能解这这挑战。
在这个过程中，架构师最终要创造什么样的价值呢？实际上，统一语义并不是一个必须进行的环节。
在两种情况下，你可以选择新式这个环节。
一种情况是你一个人做项目很清楚客户要什么，对整个项目流程有非常明确的把握。
假设你也没有多个分裂的人格，那你就没必要统一语义了。
另一种是你所在的公司已经有了统一的语义环境，从自然语言到需求描述，再到预模型定义、接口定义，再到设计实施上限维护，都有了一个非常完整的流程，也就是已经有了完整的反式数据字典指标定义和语义冲突解决方案。
那你也不需要画蛇添足。
再发明一套新的方法，去打乱现有的统一语义的流程呢？那什么时候需要统一语义呢？也案是当对话双方或者多方都在各自表达，没有办法法理解对方的真实意图的时候，就需要统一语义了。
经常有人用统一语言来描述统一语义这个过程。
我认为这种表达其实是不够精确的，因为自然语言是有歧义的。
所以统一语言其实不能保障我们这个环节的真实目的。
也就是说，在统一语义的层面上完成交流对话，双方很可能使用了同一种语言，甚至是同一种词汇。
但双方呢只是在对话，而不是在交流，因为他们没有在语义层面先达到统一。
为什么双方在不断的表达，但是却没法领会对方的意图呢？根本原因在于对话双方或者多方已经有了各自的语境。
我们这里的语境特别呢是指语义环境，为什么semantic context,而不是语言环境？ Language context,这里我要特别强调一下，但为什么对话双方会有不同的语境呢？只有搞清楚这个问题，你才能明白一个架构师在统一语义这个过程中创造的价值。
那么接下来呢我试图用一个非常长的案例来解释一下语境和语义的差异。
你可以仔细领会一下。
假设你正在主持一个国际化电商系统的商品中台构建的项目团队，之前搭建了一个实体的商品中台，目标呢是改造这个中台，让他支持虚拟商品的售卖。
比如说电影、电视、歌曲、电子票等等。
但是前台的数字电商业务团队跟中台的商品团队吵得很凶。
因为从商品中台的团队来看，因论是数字商品还是实物商品都是商品。
而数字电商团队的角度来看，此商品非比商品，所以虚拟商品不是商品。
我们先来研究一下实物商品，一个实物商品呢源自一个生产商。
这个生产商产出的呢是一个标准化的产品，产品由不同的商家采购在一个平台上售卖。
在售卖之前呢，商品被商家发布到平台上。
但实际上呢，商家发布的不是商品，而是该商家对自己所持有商品的描述，也就是一个商品描述这些不同的商品描述。
被平台规划变跟来自生产商的商品描述，校准之后就形成了一个商品。
这些商品会通过搜索、推荐、秒杀等活动而被透出给用户，是用户认为他们能购买的东西。
当用户在某个商家的店铺里下了一个订单之后，商家的履约团队就会完成订单。
把一个具体的货品，也就是商家从生产商里采购来的商品打包快递给用户。
这个描述呢可能有点抽象画了，一张图放在了文稿里。
我再拿数字电影这个例子来研究一下数字商品一个数字产品来自于一个发行商。
发行商呢为平台提供的一个商品描述平台。
根据来自其他源头的信息，比如说到晚评价，对商品描述做校准和增强之后，就形成了一个数字商品。
这个商品呢也可以由搜索、推荐、秒杀等活动分出给用户，是用户认为他们能购买的东西。
当用户下了一个订单之后呢，商家就会进入数字化履约过程完成订单，并把一个具体的数字内容和相关的授权密钥分发给用户。
这样的话用户就可以在自己的设备上观看电影了。
同样的，我把这段描述制成了一张图，放在了文稿里。
现在你可以对比一下我刚才描述的这两段话，你可能会说数字商品和实物商品的区别看起来不是很大呀。
为什么两个团队会有那么大的分歧呢？我们仔细研究一下这两段话的语境，会发现呢其中有几个不同的角色，他们各自的语境差异很大。
所以呢我们可以重新从各个角色的语境出发，再次审视刚才的两段描述。
首先呢是生产商这个角色的语境，生产商是产品的生产者，提供产品的权威描述和售后保障等等，他们一般不会跟平台直接发生关系。
当然也有一种特殊的生产商叫做品牌商，他们会验证商品的真假，或者对商品的分销价格和领域进行限制，所以他们会跟平台发生关系。
不过在我们这个语境中并不涉及品牌商。
第二个呢是售卖实物商品的商家的语境。
产品呢被商家以不同方式获取之后，这个实物的产品就到了商家的仓库中，也就是未来要发送给客户的货品。
那么商家呢就会控制这个货品的物权，甚至呢可以在原有的产品之上增加额外保障。
比如说七天免运费退款，以免换新等等。
作为商家提供商品的一部分，商家和平台发生关系，就是通过对自己货品的商品描述。
第三个呢是实物电商平台的语境平台。
在获取不同的商家的商品描述之后呢，会整合成一个平台的权威商品描述。
也就是刚才提到的商品。
并且呢会把这个商品提供给平台。
用户订单呢其实是用户和商家形成的一笔交易。
用户虽然把钱交给了平台，但是物权还在商家手里。
用户确认收货之后，钱在由平台打给商家，钱始终不属于平台并台，只是这个过程中的一个担保者。
第四个呢是平台用户的语境。
用户在平台上可以购买实物商品，也可以购买数字商品。
对他们来说，花钱就是买一个能消费的东西。
所以能享受就行了。
第五个呢是发行商的语境。
拿电影来说，发行商在某个国家或者地区里对这个电影有发行权。
发行商呢为这个地方生产一个标准的数字产品，也就是翻译好，剪辑好，并且按地区植入相关内容的数字电影。
发行商呢和一个数字电商平台达成售卖协议，由数字电商平台向用户售卖。
数字商品。
第六个呢是数字电商平台的语境，平台呢会跟多个发行商存在商务关系。
发行商呢提供一个数字产品的版权，由数字电商平台负责售卖。
数字平台呢不是在售卖一个售钱，而是这个电商在某个地区里不可转交的限定时长的，仅用于个人观看的版权。
比如说沙丘，也就是说呢这个供应商和数字平台形成的是一个寄售的商务关系。
从理论上来说呢，平台有无限的个人观看版权可以售卖，但是不用一开始就给发行商一大笔钱，而是在用户下单之后，立即跟发行商形成一笔背靠背的交易，采购一个观看版权，然后再把这个观看版权卖给用户。
第六个呢是数字内容的用户的语境。
用户可能没有意识到，他自己从来就没有买下沙丘这部电影，而是买下了自己在某个播放设备上，并且在一定时间内观看这部电影的权利。
他不可不能因为担心设备坏了而复制一份，也不方便把自己的手机借给朋友或者家人看，更不能截个短视频来进行传播。
通过刚才这些分析，你会意识到一个平台中呢存在多个角色，每个角色呢都有自己的语境。
同样一个词，比如商品或者售卖，在不同的语境下，语义可能完全不同。
大多数角色也不一定知道其他角色的存在，更不用说理解他们的语境的。
另外有些角色在自己的语境内有着正确的定义和自家的逻辑。
但是有的角色，比如说用户，他们甚至都不知道自己真正购买的是什么。
比如说大多数用户都不知道自己得到的数字商品，其实是带了很多约束条件的一次性的授权。
对他们来说呢，不论是买了货还是买了数字电影，他都是付了一份钱，得到他们需要的东西。
在他们的语境之内，数字商品和实物商品都是商品没什么差别。
也就是说呢，一个词商品你跟周围的人都在使用它。
但这个词的真实语义在随着不同使用者的角色和使用语境在不断的变化。
如果你不知道其他人的语境，那你只是在不停的说话，而没有形成真正的交流。
类似的案例还有很多类，其在一个相对复杂的场景中，不同角色的语境中有很多定义都是模糊的。
每个角色真正在乎的其实是自己的需求被准确的满足，所以根本不关心其他角色的存在。
分析到这里呢，我们其实就清楚了。
对于架构规划而言，统一语义的终极目标只有一个，那就是项目所有参与方的需求能够被无损的表达记录和传递。
然后通过架构活动实现出来，这一点对于架构师来说尤其重要。
因为你在整个架构活动是跨越多个角色而存在的。
你这个角色的全局性，就意味着你能够看到不同角色之间的语境的差异。
最终呢你需要通过一个完整的自洽的、相互兼容的设计，来满足所有角色的诉求。
有了统一的语义，你才能保障好架构活动。
接下来的规划。
它的价值呢如下，第一，架构活动的目标能够架构活递并分解给每个参与者。
第二，所有参与者的诉求都能够为准确的表达记录和传递。
第三，架构活动的目标和所有需求能够反映到整体的架构规划中第，且能够被无损的拆分到多个子领域的任务中。
第四，需求方能够得到执行方的真实反馈，从而对整个架构活动产出有个合理的期望。
第五，每个子领域交付，并且组装好之后，能够语义契合，相互兼容，最终符合架构活动的整体目标。
我把刚才讲的这五方面的关系做成了一张图，放在了文稿里。
我一来解释一下这张图，从某种角度来说，架构规划这件事上，架构师呢扮演的是一个律师的责任。
你要确保所有参与方都使用同一个语境来表达自己的角色，确认自己的责任。
首先呢你作为这个架构师呢，要确保自顶向下的目标的正确性、合理性和可达性。
最后，在统一语义的环境中，你需要构造或确认需求，划分边界拆分任务，并确认整个架构规划的完整性。
最后你需要跟每个执行者确认，他在各构规划所要承担的责任，帮助需求方和执行方把这些内容撰写成一个交付合同，并将各方确认同时完成自己的工作。
在联调阶段还要重新组装成完完整的系统，比最终呢最小化跨团队的交付风险，达到预期的目标。
需要注意的是呢，你这个统一语义的场景仅仅适用于架构活动中跨团队的交流。
至于执行方团队内部是不是要使用你的语境，那完全是他们的选择。
事实上呢你也没办法干涉。
我们可以想象，在一种极端的情况下呢，你用一个形式语言描述了整个架构规划，也确保了规划的正确性、合理性和可达性。
你非常懂业务，也能清晰理解所有用户的觉需求。
你也懂十几种架构方言，把你的任务呢无损拆分后，再翻译成这些方言。
最后呢你再把拆好的规划交给讲这个架构，方圆的团队去完成。
如果你能真的做得到这些，那这个路径呢同样也是OK的。
因为这个过程的本质是你没有要求所有人都统一语境，而是你呢或者是你的小团队用一个形式语言统一了大家的语境。
我分享这个场景呢，并不是建议你这么做。
实际上我也从来没见有人这么做过。
而是想通过这个例子呢，我想说明呢统一语义的目的并不是为了统一参与者日常工作的语言，而是确保整个架构规划在一个逻辑完备并且语义一致的环境中，而完成架构规划的全生命周期的信息流转。
因为这个假想的例子是集中式的，而不是一个分布式的方案。
这么做呢也就会形成一个单点。
也就是说，你或者是你的架构团队，是整个架构活动中唯一具有完整语义的人。
但是一个架构师的业务理解，逻辑推理能力和工作经历毕竟是有限的。
所以在了互联网时代呢，大家更喜欢用第一种玩法，也就是现在所有参与者之间统一语义，然后参与者呢在同一个语义环境下进行交流和协作。
好了，今天讲的内容呢就是这么多。
我来总结一下，我们花了一整节的课程，把统一语义这个环境价值讲清楚了。
事实上，哪怕在架构活动之外，我们的生活中呢也有非常多需要统一语义的地方。
就像我妈妈爸爸一起生活了五十多年了，我经常能观察他们俩完全是在不同的语义环境中，各自跟虚拟空间中的自己吵架，而不是跟对方吵。
所以呢你学习了语义环境之后，不一定能让你不跟别人吵架，但至少你别跟自己过不去。
最后呢是思考题环节。
不过今天呢我想用一些轻松的作业来调节一下课堂气氛。
第一题呢你可以分享一个关于名字含义的笑话吗？我先来啊，不是我发明的一个啊一个男生呢，早上误了公交车，边追边喊，师傅，你等一下，司机回到了悟空，你就别追啦。
第二题呢没有解决语境的分歧呢，最终呢会通过架构方案一直渗透到代码数据模型的最底层，导致很离奇的函数名表定义、依赖关系和消息团体。
你有没有见过类似的案例呢？啊，第三题从小到大呢，我们肯定会因为错误理解的语义而造成一些麻烦。
比如说你的初恋，说今天太晚了，打不到车了。
于是呢你在风中苦苦等了半个钟头，才帮他拦下一辆出租车，但是初恋呢却一点也没高兴起来。
你有没有类似的经历呢？可以分享一下。
如果这节课对你有帮助，欢迎你把课程转发给你的同事或者朋友，顺便呢打一个小广告。
我刚刚开了个人抖个人。
抖音号呢我已经发表了一些比较新，但是并没有那么成熟的观点呢。
欢迎大家抖音上搜索郭东白并关注，也欢迎你的批评指正，我们下节课再见，拜拜。