你好，我是郭东白。从这节课开始，我们就进入到架构活动的第四个环节——架构规划。这个环节比较复杂，可以分为四个部分：统一语义、需求确认、边界划分和规划确认。这节课我们先来讲统一语义。
架构师的工作日常就是跟不同的角色沟通。然而每个角色的认知和语言，都在各自的职能与工作环境中逐渐形成并固定。如果没有统一语义的过程，那么整个架构活动就好像每个人都做了一个梦，在各自的梦境中似乎玩得很开心，醒来后却发现没有任何改变。
想要架构活动最终能达到预期目标，就需要从统一语义开始我们整个架构的规划。
为什么要统一语义？
听到统一语义，你估计会产生这么一连串的疑问：
- 统一语义到底是做什么的？为什么值得做？
- 统一语义听起来很简单啊，有什么挑战在里面吗？
- 我作为架构师，在这个环节中能创造什么价值吗？
需要注意的是，统一语义并不是完全必须的环节。在两种情况下，你可以选择忽略这个环节。
一是只有你一个人做项目，很清楚客户要什么，对整个项目流程也有着非常明确的把握。假设你也没有多个分裂的人格，在这种情况下就没必要统一语义了。
另一种是，你所在的公司已经有了统一的语义环境。从自然语言到需求描述，再到域模型定义、接口定义，再到设计、实施、上线维护，都已经有了从完整的范式、数据字典、指标定义和语义冲突解决（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）描述了整个架构规划，也确保了架构规划的正确性、合理性和可达性。你极懂业务，可以清晰理解所有用户角色的需求。你也懂十多种架构方言，可以把你的任务无损拆分后再翻译成架构方言。最后，再把拆分好的规划交给讲这个架构方言的团队去完成。
如果真的能做到这些，那这个路径也行得通。因为统一语义这个过程的本质，并不是要求所有参与者都统一语境，而是你或者你的小团队在使用一个形式语言，达到统一语境的目的。
不过我分享这个场景，并不是建议你这么去做。事实上，我也从来没见过有人能做到。通过这个例子我想说明的是，统一语义的目的不是为了统一参与者日常工作的语言，而是确保整个架构规划在一个逻辑完备且语义一致的环境中，能完成架构规划全生命周期的信息流转。
因为这个假想的例子是集中式而不是分布式的方案，这么做会形成一个单点。也就是只有你或者你的架构团队，是整个架构活动中唯一具备完整语义的人。但一个架构师的业务理解、逻辑推理能力和工作精力毕竟是有限的，所以在互联网时代，大家更喜欢用第一种玩法。也就是先在所有参与者之间统一语义，然后让参与者在同一个语义环境中交流和协作。
小结
我们今天花了一整节课的时间，把统一语义这个环节的价值阐述清楚了。事实上，哪怕在架构活动之外，我们生活中也有非常多需要统一语义的地方。就像我妈妈爸爸一起生活五十多年了，但很明显，他们俩生活在完全不同的语义环境中。一旦吵架了，也是在跟虚拟空间中的自己吵架，而不是跟对方吵。
所以学习了语义环境，不一定能让你不跟别人吵架，但我们至少别跟自己过不去啊！
思考题
两个作业，任选一个来作答。不过我想用一些轻松的作业来调节一下课堂氛围。
- 可以分享一个关于名字含义的笑话吗？我先来：
一个男生早上误了公交车，边追边喊：“师傅， 你等一下…”
司机回：“悟空 , 你就别追啦…”
- 如果不解决语境的分歧，那么这个问题最终会透过架构方案，一直渗透到代码和数据模型的底层，导致很离奇的函数名、表定义、依赖关系和消息传递。你见到过最离谱的类似的案例是什么？可以分享出来。