节点四:架构规划之统一语义

架构系列课专栏目录总览

从这节课我们就开始学习架构活动的第四个环节——架构规划。这个环节比较复杂,可以分为四个部分:统一语义、需求确认、边界划分和规划确认。这节课我们先来讲统一语义。

架构师的工作日常就是跟不同的角色沟通。然而每个角色的认知和语言,都在各自的职能与工作环境中逐渐形成并固定。如果没有统一语义的过程,那么整个架构活动就好像每个人都做了一个梦,大家各自在自己的梦境中似乎玩得很开心,醒来后却发现没有任何改变。

想要架构活动最终能达到我们共同的预期,那么就需要从统一语义开始我们整个架构的规划。

为什么要统一语义?

听到统一语义,你估计会产生这么一连串的疑问:

统一语义到底是做什么的?为什么值得做?

统一语义听起来很简单啊,有什么挑战在里面吗?

我作为架构师,在这个环节中能创造出什么价值吗?

需要注意的是,统一语义并不是完全必须的环节。在两种情况下,你可以选择忽略这个环节。

一是只有你一个人做项目,很清楚客户要什么,你也对整个项目流程有着非常明确的把握。那么假设你也没有多个分裂的人格,这种情况下就没必要统一语义了。

另一种是,你所在的公司已经有了统一的语义环境。从自然语言到需求描述,再到域模型定义、接口定义,再到设计、实施、上线维护,都已经有了从完整的范式、数据字典、指标定义和语义冲突解决(conflict resolution)的流程。那么你也不需要画蛇添足,再发明一套新的方法去打乱现有的统一语义的流程了。

那么什么时候需要统一语义呢?答案是当对话双方或者多方在各自表达,但却没有办法理解对方真实意图的时候,就需要统一语义了。

经常有人用统一语言来表征统一语义这个过程,我认为这么表达其实是不够精确的。要知道,自然语言是有歧义的,因而统一语言(Unified language)并不得保障我们这个环节的真实目的:在统一语义的层面上完成交流(Semantic exchange)。对话的双方很可能使用了同一种语言,甚至是同一组词汇,但双方只是在对话而不是在交流,因为他们没有在语义层面先达到统一。

为什么双方在不断表达,却还是没法领会对方的意图呢?根本原因在于对话双方或多方已经有了各自的语义环境(Semantic 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)描述了整个架构规划,也确保了架构规划的正确性、合理性和可达性。你极懂业务,可以清晰理解所有用户角色的需求。你也懂十多种架构方言,可以把你的任务无损拆分后再翻译成架构方言。最后,你再把拆分好的规划交给讲这个架构方言的团队去完成。

如果你真的能做到这些,那么这个路径也行得通。因为统一语义这个过程的本质,并不是要求所有参与者都统一语境,而是你或者你的小团队,在使用一个形式语言,达到统一语境的目的。

不过我分享这个场景,并不是建议你这么去做。事实上,我也从来没见过人这么做过。但是通过这个例子我想说明的是,统一语义的目的不是为了统一参与者日常工作的语言,而是确保整个架构规划在一个逻辑完备且语义一致的环境中,能完成架构规划全生命周期的信息流转。

因为这个假想的例子是集中式而不是分布式的方案,这么做会形成一个单点。也就是只有你或者你的架构团队,是整个架构活动中唯一具备完整语义的人。但一个架构师的业务理解、逻辑推理能力和工作精力毕竟是有限的,所以在互联网时代,大家更喜欢用第一种玩法。也就是先在所有参与者之间统一语义,然后让参与者在同一个语义环境中交流和协作。

小结

我们今天花了一整节课的时间,把统一语义这个环节的价值阐述清楚了。事实上,哪怕在架构活动之外,我们生活中也有非常多需要统一语义的地方。就像我妈妈爸爸一起生活五十多年了,但很明显,他们俩生活在完全不同的语义环境中。一旦吵架了,也是在跟虚拟空间中的自己吵架,而不是跟对方吵。

所以你学习了语义环境,不一定能让你不跟别人吵架,但是我们至少别跟自己过不去啊!

免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » 节点四:架构规划之统一语义