23 节点四：架构规划之统一语义
你好，我是郭东白。从这节课开始，我们就进入到架构活动的第四个环节——架构规划。这个环节比较复杂，可以分为四个部分：统一语义、需求确认、边界划分和规划确认。这节课我们先来讲统一语义。
架构师的工作日常就是跟不同的角色沟通。然而每个角色的认知和语言，都在各自的职能与工作环境中逐渐形成并固定。如果没有统一语义的过程，那么整个架构活动就好像每个人都做了一个梦，在各自的梦境中似乎玩得很开心，醒来后却发现没有任何改变。
想要架构活动最终能达到预期目标，就需要从统一语义开始我们整个架构的规划。
为什么要统一语义？
听到统一语义，你估计会产生这么一连串的疑问：
- 统一语义到底是做什么的？为什么值得做？
- 统一语义听起来很简单啊，有什么挑战在里面吗？
- 我作为架构师，在这个环节中能创造什么价值吗？
需要注意的是，统一语义并不是完全必须的环节。在两种情况下，你可以选择忽略这个环节。
一是只有你一个人做项目，很清楚客户要什么，对整个项目流程也有着非常明确的把握。假设你也没有多个分裂的人格，在这种情况下就没必要统一语义了。
另一种是，你所在的公司已经有了统一的语义环境。从自然语言到需求描述，再到域模型定义、接口定义，再到设计、实施、上线维护，都已经有了从完整的范式、数据字典、指标定义和语义冲突解决（Conflict Resolution）的流程。那么你也不需要画蛇添足，再发明一套新的方法去打乱现有的统一语义的流程了。
那么什么时候需要统一语义呢？答案是当对话双方或者多方在各自表达，没有办法理解对方真实意图的时候，就需要统一语义了。
经常有人用统一语言来表征统一语义这个过程，我认为这么表达是不够精确的。要知道，自然语言是有歧义的，因而统一语言（Unified Language）并不能保障我们这个环节的真实目的：在统一语义的层面上完成交流（Semantic Exchange）。对话的双方很可能使用了同一种语言，甚同一组词汇，但双方只是在对话而不是在交流，因为他们没有在语义层面先达到统一。
为什么双方在不断表达，却还是没法领会对方的意图呢？根本原因在于对话双方或多方已经有了各自的语境。需要特别强调的是，这里的语境是指语义环境（Semantic Context），而不是语言环境（Language Context）。
为什么会有语境差异？
接下来我就用一个篇幅比较长的案例来解释一下语境的差异。通过这个案例，希望你能了解语境差异给交流带来的巨大障碍。
案例描述
假设你正在主持一个国际化电商系统的商品中台构建的项目。团队之前搭建了一个实体商品中台，目标是改造这个中台，让它支持虚拟商品的售卖，比如电影电视、歌曲、电子票等。
但是前台的数字电商业务团队和中台的商品团队吵得很凶：
- 从商品中台团队的角度看，无论是数字商品还是实物商品，都是商品。
- 而从数字电商团队的角度看，此商品非彼商品，虚拟商品不是商品。
我们先来研究一下实物商品。一个实物商品源自一个生产商，这个生产商产出的是一个标准的产品（Product）。产品由不同的商家采购，在一个平台上售卖。在售卖前，商品被商家发布到平台上。但实际上，商家发布的不是商品，而是该商家对自己所持有产品的描述，也就是一个商品描述（Listing）。
这些不同的商品描述被平台归一化，并与来自生产商的产品描述校准后，就形成了一个商品（Item）。这个商品会通过搜索、推荐、秒杀等活动被透出给用户，是用户认为他们能购买的东西。当用户在某个商家的店铺里下了一个订单（Order） 后，商家的履约团队就会完成订单。把一个具体的货品（Inventory Unit），也就是商家从生产商那里采购来的产品，打包快递给用户。如下图所示：
我们再以数字电影为例来研究一下数字商品。一个数字产品（Digital Product） 源自一个发行商。发行商为平台提供了商品描述(Listing)。而平台呢，会根据来自其他源头的信息（比如豆瓣评价）对商品描述做校准和增强，然后形成一个数字商品(Digital Item)**。
这个商品也可以由搜索、推荐、秒杀等活动透出给用户，是用户认为他们能购买的东西。当用户下了一个 订单（Digital Order）后，商家就会进入数字化履约过程完成订单，把一个具体的数字内容（Digital Content）和相关的授权密钥 （License key）分发给用户，那么用户就可以在自己的设备上观看电影了。如下图所示：
对比一下刚才这两段描述，似乎数字商品和实物商品的区别不大啊？那为什么两个团队之间会有那么大的分歧呢？
我们仔细研究一下这两段描述的语境，会发现其中有几个不同的角色，他们各自的语境差异很大。因而我们可以重新从各个角色的语境出发，再次审视上面的描述。
案例阐释
首先是生产商的语境。生产商是产品的生产者，提供产品的权威描述和售后保障等。他们一般不会与平台直接发生关系。当然，也有一种特殊的生产商叫做品牌商，他们会验证商品的真假，或者对商品的分销价格和领域等进行限制，因此会与平台发生关系。不过在我们这个语境中并不涉及品牌商。
第二个语境是售卖实物商品的商家。产品被商家以不同方式获取后，这个实物的产品就到了商家的仓库中，也就是未来要发送给客户的货品。那么商家将会控制这个货品的物权，甚至会在原有产品中增加额外保障，比如7天免运费退款、1年换新等，作为商家提供的商品的一部分。可以说，商家和平台发生关系，就是通过提供对自己货品的商品描述。
第三个语境是实物电商平台。平台在获取不同商家的商品描述后，会整合成一个平台的权威商品描述，也就是刚才提到的商品（Item），并把商品提供给平台用户。订单则是用户和商家形成的一笔交易。用户虽然把钱交给了平台，但物权还是在商家手里。用户确认收货之后，钱再由平台打给商家。需要注意的是，钱始终不属于平台，只是这个过程中的一个担保者。
第四个语境是平台用户。用户在平台上可以购买实物商品，也可以购买数字商品。对于他们而言，花钱就是买一个消费的东西（Consumable Item），能享受就行了。
第五个语境是发行商。拿电影来举例，发行商在某个国家或者地区内对这个电影有发行权。他们会为该地生产一个标准的数字产品(Digital Product)，也就是翻译好、剪辑好，并且按地区植入相关内容的数字电影。除此之外，发行商也会和一个数字电商平台达成售卖协议，然后由这个数字电商平台向用户售卖数字商品（Digital Item）。
第六个语境是数字电商平台。平台跟多个发行商都存在商务关系。发行商提供一个数字产品的版权，由数字电商平台负责售卖。数字平台不是在售卖一个电影，而是这部电影在某个地区内不可以转交的、在限定时长内的、仅仅用于个人观看的版权，比如《沙丘》这部电影。
也就是说，这个供应商和数字平台形成的是寄售（Consignment）的商务关系。从理论上来讲，平台上有无限的个人观看版权可以售卖，不过并不需要在一开始就给发行商一大笔钱。而是在用户下单之后，立即和发行商形成一笔背靠背的交易，采购一个观看版权，然后再把观看版权卖给用户。
第六个语境是数字内容的用户。用户可能没有意识到，自己从来都没有买下《沙丘》这部电影，而只是买到了自己在某个播放设备上，且在一定时间内观看这部电影的权利。用户不能因为担心设备坏了而复制一份，也不方便把自己的手机借给朋友或者家人看，更不能截个短视频来传播获利。
通过上述这些分析，你会意识到，一个平台中存在多个角色，而每个角色都有着从各自视角出发而形成的语境。同样一个词，比如商品或者售卖，在不同的语境下，语义很可能完全不同。但是大多数角色不一定知道其他角色的存在，更不用说理解他们的语境了。
此外，有的角色在自己的语境内有着正确的定义和自洽的逻辑。但是有的角色，比如说用户，可能都不知道自己得到的数字商品，其实是带有很多约束条件的一次性授权。对于用户来说，无论购买商品还是购买数字电影，都是付了一份钱，得到了自己需要的东西。在他们的语境内，数字商品和实物商品都是商品，没有什么差别。
也就是说，一个词，比如商品，你与周围人都在使用。但这个词的真实语义，却因为使用者角色及其语境的不同，在不断切换。如果你不知道其他人的语境，那你们就是在不停地对话，却没有达到交流的目的。
类似的案例还有很多。尤其在一个相对复杂的场景中，不同角色的语境中有很多定义都是模糊的。每个角色真正最在乎的，其中只是自己的需求被准确地满足，而根本不关心其他角色在表达什么。
架构师在统一语义中的价值
分析到这里我们就清楚了，对于架构规划而言，统一语义的终极目标只有一个：项目所有参与方的需求能够被无损地表达、记录和传递，然后通过架构活动实现出来。
这一点对于架构师来说尤其重要，因为你在整个架构活动是跨越多个角色而存在的。这个角色的全局性，意味着你需要看到不同角色之间的语境差异，然后通过一个完整的、自洽的、相互兼容（Interoperable）的设计，来准确地满足所有角色的诉求。
因为有了统一的语义，你才能保障好架构活动接下来的规划。具体而言，统一语义的价值包括如下几个方面：
- 架构活动的目标，能够清晰传递并分解给每个参与者；
- 所有参与者的诉求，能够被准确地表达、记录和传递；
- 架构活动的目标和所有需求，能够反映到整体的架构规划中，并且能够被无损地拆分到多个子领域的任务中；
- 需求方能得到执行者的真实反馈，从而对整个架构活动的产出有个合理的期望；
- 每个子领域交付并组装好之后，能够语义契合、相互兼容，最终符合架构活动的整体目标。
如下图所示：
从某种角度来说，架构师在架构规划中扮演的是律师的角色，需要确保所有参与方都在使用同一个语境来表达自己的需求，确认自己的责任。
- 作为架构师，要确保从顶自下的目标的正确性、合理性和可达性。
- 然后在统一语义的环境中，构造和确认需求、划分边界、拆分任务，并确认整个架构规划的完整性。
- 最后，还需要跟每个执行者确认他在架构规划所要承担的责任，帮助需求方和执行者把这些内容撰写成一个交付合同，并让各方确认，然后去完成各自的工作。在联调阶段，又重新组装成完整的系统，最终最小化跨团队的交付风险，达到预期目标。
需要注意的是，这个统一语义的场景，仅仅适用于架构活动中跨团队的交流。至于执行方团队内部是否要使用这个语境，那完全是他们的选择，事实上你也无法干涉。
我们可以想象在一种极端的情形下，你用一个形式语言（Formal Language）描述了整个架构规划，也确保了架构规划的正确性、合理性和可达性。你极懂业务，可以清晰理解所有用户角色的需求。你也懂十多种架构方言，可以把你的任务无损拆分后再翻译成架构方言。最后，再把拆分好的规划交给讲这个架构方言的团队去完成。
如果真的能做到这些，那这个路径也行得通。因为统一语义这个过程的本质，并不是要求所有参与者都统一语境，而是你或者你的小团队在使用一个形式语言，达到统一语境的目的。
不过我分享这个场景，并不是建议你这么去做。事实上，我也从来没见过有人能做到。通过这个例子我想说明的是，统一语义的目的不是为了统一参与者日常工作的语言，而是确保整个架构规划在一个逻辑完备且语义一致的环境中，能完成架构规划全生命周期的信息流转。
因为这个假想的例子是集中式而不是分布式的方案，这么做会形成一个单点。也就是只有你或者你的架构团队，是整个架构活动中唯一具备完整语义的人。但一个架构师的业务理解、逻辑推理能力和工作精力毕竟是有限的，所以在互联网时代，大家更喜欢用第一种玩法。也就是先在所有参与者之间统一语义，然后让参与者在同一个语义环境中交流和协作。
小结
我们今天花了一整节课的时间，把统一语义这个环节的价值阐述清楚了。事实上，哪怕在架构活动之外，我们生活中也有非常多需要统一语义的地方。就像我妈妈爸爸一起生活五十多年了，但很明显，他们俩生活在完全不同的语义环境中。一旦吵架了，也是在跟虚拟空间中的自己吵架，而不是跟对方吵。
所以学习了语义环境，不一定能让你不跟别人吵架，但我们至少别跟自己过不去啊！
思考题
两个作业，任选一个来作答。不过我想用一些轻松的作业来调节一下课堂氛围。
- 可以分享一个关于名字含义的笑话吗？我先来：
一个男生早上误了公交车，边追边喊：“师傅， 你等一下…”
司机回：“悟空 , 你就别追啦…”
- 如果不解决语境的分歧，那么这个问题最终会透过架构方案，一直渗透到代码和数据模型的底层，导致很离奇的函数名、表定义、依赖关系和消息传递。你见到过最离谱的类似的案例是什么？可以分享出来。
如果这节课对你有帮助，欢迎把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！
- kq yang 👍（24） 💬（2）
伟大的人物考虑的主题总是相似的。卡尔波普在他的文集，通过知识获得解放中的 《框架的神话》详细探讨了不同的文明或对话是否需要基于统一的对话框架。和许多人的直观感受不一样的是，理论层面并不需要。每一个体系都可以经由借鉴和重新发明来完成沟通对话，每一个体系依然可以独立而不需要完全的融合。 现实中，没有统一的框架的确会极大限制沟通的效率。所以名实问题也是百家之经典。爱因斯坦也说了，提出概念的能力是理解和把握这个世界的核心能力。有这种意识和能力，全世界才能演进成为一个共同的批判体。以前像尼古拉·特斯拉这样的超级牛人可以创建自己版本的电动力学，但是现在的世界不断坍缩，孤立的小世界太难持续了。还是融入大同世界才是法门。 但是概念的提出，绝大多数时候都是完全不必要的。绝大多数时候人们需要的其实是格式塔心理学。也就得有奥卡姆剃刀的风格，剩下的才是需要提出的东西。每个梗的提出都是无脑的炫技，人类总是因自己的独特而认同自己和群体，哪怕因此愚蠢和战争。但我们比较卡尔波普和哈贝马斯的风格我们能够被真正的伟大打动。真正的伟大，是简洁和人话，是大卫·奥格威口中的动词和名次，是绝不浪费着别人的生命。
2022-03-24 - 术子米德 👍（7） 💬（1）
🤔☕️🤔☕️🤔 * 📖：统一语义，走出各自的梦境，大家在真实的世界里，准确无误地交流。 * 🤔：统一语义，走出梦境，难嘛？极难。我说模块，它叫Module，你也这么说、这么叫，它们名字一样，可是我们的理解可能有偏差。我认为模块是静态的，针对开发而言，主要是以某个开发的源代码为主要组成。你认为打包在一起，能够部署到系统里，能够被使用起来的才叫模块。差别来自我们都在自说自话，懒得坐下来，在架构层面将其定义清楚。而这种懒得，可能又是对架构的这个相同词的不同理解导致，我以为架构就是要先定义，你只看得上所谓的架构图，只要是分层图，里面画些框，框里填写字，就是架构。不屑，也更懒得去思考，架构到底意味着什么，反正曾经一本忘记书名的书上画的架构图如此，那就一直根深蒂固地如此这般着。这么说来，统一语义的第一大敌就是自己的深以为然，却不带半点对文字的力量的敬畏。 * 🤔：反过来想，遇到愿意在一开始坐下来，一起讨论最基础的概念，一起定义清楚其内涵和外延，算是遇到知音级，或者至少是具备相同架构认知，更或者说是学习本课后，深以为然在架构初期，最值得开展的活动之一，就是进行统一语义的活动。 * 🤔：把统一语义比做书同文、车同轨，这样才能让信息在全国传播不失真，这样才能让车轱辘有可能以较高效率跑遍全国。
2022-03-28 - Ryoma 👍（3） 💬（1）
A：最近看过一个很好看的电影，叫什么山来着？我一时想不起来 B：断背山？ A：不是 B：诺丁山？ A：不是 A：哦，我想起来了，碟中谍3
2022-08-31 - ， 👍（3） 💬（1）
这节课让我想起了谭sir与二仙桥大爷的经典对话: 谭sir:你该走哪?(非机动车能走机动车道吗?) 大爷:走二仙桥,去成华大道(我要去成华大道,当然要走二仙桥) 谭sir:能啦吗?(你三轮车能超载吗) 大爷:能拉,只能拉一点点(我的车拉得动这些货)
2022-05-11 - 顾小平 👍（2） 💬（1）
统一语义确实很重要，如果更上升到管理以及组织的治理上这点可能更加重要，前段时间读到理想汽车关于LBP工作法，就是把来自不同行业背景，以及不同业务单元的人都能在“同一个世界”里思考，交流，工作，不仅仅方向一致，工作效率也能极高，这也是理想汽车发展迅速非常重要的一个原因；
2022-07-26 - 郭桑 👍（1） 💬（1）
请问郭老师，在这个环节架构师会不会与企业中数据管理相关的角色有合作呢？一般是谁来主导统一语言的过程呢？统一后的语言的标准和定义一般会在哪里维护和管理呢？ 本人前阵子遇到了个案例，要统计生产不同“产品”的碳排放量。这个“产品”业务上定义的很宽泛，装配线下线的也算、机加线下线的也算、铸造后的也算、对外销售的也算，因为涉及许多生产单位，统计口径和命名规则也是五花八门。后来我们和主管部门统一了一下语言，认为产品是由销售来定义，主要指公司层面、有价格、对外销售的产品；生产下线的产品由生产管理部门定义，统一定义为“产成品”、“半成品”。但是目前仅仅是在这个项目中做到了语言统一，尚不清楚该如何上升到公司层面。不知道郭老师有什么建议？
2022-09-14 - 罗均 👍（1） 💬（2）
谢谢老师的课程！ 有一个关于“架构师”的话题，不知道算不算笑话，但是每次与同行聊起来，他们都很好笑。 汽车制造商里有很多不同类型的架构师，例如： -整车架构师(定义底盘和动力总成)， 产品架构师(定义车型功能配置)， 网络架构师又分两种，一种是TCP/IP组网为主，另一种是车内CAN总线为主， 系统架构师也分两种，一种是车内的，另一种是车联网的(车<->云<->手机)， 软件架构师一般指车内嵌入式Linux系统软件的架构师，一般用Enterprise Architecture提供UML给开发团队， java架构师和互联网的一样，主要是熟悉spring和数据库设计云端架构， 还有安全架构师， 加起来种9架构师！其在交流时，几乎70%的时间，都是在澄清彼此的语义，如果遇到傲慢或脾气不好的人，那就有好戏看了。
2022-03-22 - huzhengyao 👍（0） 💬（1）
文中关于产品，商品，货品的图有啥资料书籍可以推荐下，加深下认知
2022-11-16 - shenmezi 👍（0） 💬（2）
自造一些名词并不高大上，请用大白话
2022-06-15 - Helios 👍（1） 💬（1）
有点像辩论，第一句就是“什么是某某（比如什么是英雄）”，然后再阐述观点。
2022-07-14 - spark 👍（1） 💬（0）
郭老师，take away~~~ 做事是有道和术的区别，这篇文章强调道。用乔布斯的话理解，”把一个问题定义清楚，几乎就找到了问题的解决方案“。沟通和能够达成共识的距离，很远。用”统一语义“的方法实现达成共识的目标~~~
2022-03-22 - 咏晨桃 👍（1） 💬（0）
接下来DDD的方法论上场了
2022-03-22 - 小昭 👍（0） 💬（0）
统一语义不等于统一语言，一字之差，差之千里。
2023-05-11 - 亚林 👍（0） 💬（0）
可能是我太笨了吧，只理解了统一语义的意义，还是不知道怎么落地😭
2022-07-20 - shawn 👍（0） 💬（0）
沟通过程中需要带有客户思维，这里的客户是下属，上级，产品，运营等，学会站在他们的角度上看待问题，然后把这些问题抛出来和他们一一确认。
2022-07-18