首页 > 其他分享 >郭东白的架构课25

郭东白的架构课25

时间:2022-12-17 16:56:54浏览次数:39  
标签:25 架构 语境 角色 不同 语义 郭东白 分歧 定义

你好,我是郭东白。上节课我们通过一个篇幅比较长的电商案例,详细展示了为什么在架构活动中会出现语义分歧。同时也描述了,架构师在统一语义这个环节中所要创造的真正价值是什么。即,看到不同角色之间语境的差异,然后通过一个完整的、自洽的、相互兼容的设计,来满足所有角色的诉求。

那么这节课,我们来继续分析语义分歧的根源,然后看看怎么消除语义分歧。

语义环境的差异

语境是指语义的环境(Semantic Context)。我们上节课提到了,同一个词在不同的语境下,语义很可能完全不同。但是大多数角色都不一定知道其他角色的存在,更不用说理解他们的语境了。

如下图所示,展示了语境的差异:

这张图里有多个角色,每个角色都有自己的语境。在两个角色的交互过程中,通过统一语境又出现了新的语境。

比如“平台—用户语境”或者“平台—商家语境”,在图中用不同颜色的圆圈来表示。如果这个统一的语境能够扩大,便可以包含所有角色,最终形成全局统一的语境。

语义分歧的根源

事实上,我们上节课举的由于语境差异而带来语义分歧的例子,并不是特例。想想看,我们在架构设计中、需求实现中肯定都能见到不少类似的例子。为什么会是这样呢?这其实是哲学领域里争论了数百年的问题。

如下图所示:

假设物理世界有一个存在(Being,名词),也就是图中的绿色部分。那么主体,简单来说就是你和我。我们可以在各自的意识中对这个“存在”形成认知,也就是图中的客体。

唯物主义者认为,存在是先于主体和客体的。而且是客观的,独立于我们的意识而存在的,不以你我的意志为转移的。

而主观唯心主义者认为,只有你我意识中形成的客体是真实存在的,而那个“存在”却不是第一性的。

我们先不讨论谁对谁错。但是在“世界上所有人都有认知分歧”这一点上,大家反倒是没有分歧的。也就是说,我们各自主观意识中形成的客体,我们能表达给其他人的关于客体的描述,以及我们试图在多个人中间建立的对这个存在的共识,这三者是不等价的。而这种不等价,就是语义分歧的根源。

目前来讲,我们至少不能把多个人的意识拉通到一个共享的认知领域里。除了那些因为大量日常交互而已经形成固定语境的情况外,大多数时候,不同角色之间的语境都是不同的。因此,同一个词对于不同的人来说,在语义上肯定是有分歧的。所以我们能做的,就是想办法把这个客观存在的语义上的分歧表达出来。然后试图用文字、图片、建模工具等方式来准确描述语义,减少甚至消除语义上的分歧。

这种由于语境多样性而造成的语义差异,在互联网企业中更为普遍和严重。原因如下:

  • 互联网企业一般是跨国企业,员工的文化、语言和认知本身就有差异。
  • 互联网企业的组织复杂度大,不同角色有不同的视角,他们的认知也有差异。
  • 互联网企业的场景跨度很大,在不同的使用场景下,语义也会发生变化。比如说一件商品,在大促、秒杀、团购、社区团购、物流履约和售后的场景下,含义会有所不同。
  • 互联网时代用户体验迭代很快,不同的展现方式,比如文字、图片、短视频、直播、VR,会把一个实体以不同的方式投射给一个主体,那么主体形成的语义认知必然会有所不同。
  • 信息时代引起了我们生活方式的剧烈变化,一个实体的语义会随着时间而扩充、迁移或者消亡。你翻开随便一本新华字典,看看古代人把“马”这个实体类型分得多么细。而到了现代,你要是能分清楚骡子和马,就算是博学了。

如何消除语义的分歧?

那么如何消除语义的分歧呢?

第一步,发现不同的语境。每一个交互场景其实都存在着多个角色,每个角色都有自己的独立语境。比如商家从供应商那里采购实体商品这个场景,就有它的独立语境。而商家给供应商打款,虽然交互双方没有变化,但是新的场景又会带来的语境。

就像我们在上节课给出的实体电商模型图里表示的,这些语境之间有一定的连续性。但如果我们深挖到细节,会发现其中的差异并不小。当然,我们的目的不是为了寻找绝对意义上的语义保真,而是为了给架构活动建立统一的语义环境。

所以这个发现,绝不是一个无止境的探索。我们必须保留语义差异来提供差异化的流程和服务,但是并不需要引入太多的分支,避免给用户带来不必要的复杂性。

第二步,定义概念。一旦发现了一个新的语境中,存在词语表达相同但语义不同的概念,那就需要准确描述这些概念了。就像我们上节课给出的例子。你不但要给出一个概念,更要准确描述这个概念背后的场景。

  • 在这个过程中,你需要跟不同参与方进行访谈,然后通过准确定义概念来发现不同语境之间的差异点。最后再试图把多个概念放在一起,看它们是否能完全自洽。
  • 在这个过程中,你需要不断修正自己下的定义。如此循环往复,来螺旋式提升你跟参与者的认知。
  • 在这个过程中,你的角色不是PMO,所以绝不是发一封邮件,通知大家各自完成一页Wiki Page就完事了。而是要深入到每个语境中,理解每个角色的真实诉求和语义差别。

总的来说,这仍然是一个深度思考和不断探索的过程。

第三步,语义建模。当完成了单个概念的定义后,就需要把不同概念引入到同一个语境中,也就是将两个不同的语境进行合并。这个过程,其实就是把上节课给出的两张图合并成一张图。图中的绿色部分,也就是被融合的实体的语义,需要与融合前语境中的语义基本保持一致。而蓝色部分,指的是每个实体有各自的语义,需要保留。

第四步,反馈修正。一旦形成了统一的语境,就需要跟所有参与者确认这个统一语境的正确性。要时刻记住,你作为架构师并没有什么特殊之处,也只是一个独立的个体。你的认知也仅仅是存在于自己语境中的认知,所以必须要与所有人重新确认并多次调整,才有可能找到基本正确的统一语境。

第五步,公布、维护和使用统一的语境。指的是不断使用和打磨实体定义,最终为企业带来统一语境。这个过程就是从自然语言到需求描述、到域模型定义的过程,未来也会延申到接口定义、模块设计、代码实现、上线使用等。

最终,这些过程都对之前的定义形成反馈闭环。如果你把语义的定义和维护做到极致,那么它就是一个基于标准化、中央化的实体定义和数据字典,以及围绕这些定义而制定的语义冲突解决(Conflict Resolution)的管控流程。也就是说,最终会建设一个完整的语义管理体系。

需要注意的是语境的差异。我们讲建模,其实已经默认所有的客体都放在了同一个语境中。我们也不再区分不同主体视角中的客体,而将它们统称为实体。但是实际上,建模过程中最难的一步,就是从不同语境中的主体那里,推导出一组统一语境中的实体。

关于建模我还想提一点。我在法则四中强调过必须向技术环境借力。要知道,大多数领域都有相对成熟的工业标准,并不需要发明创造太多的概念。如果真的下定决心去整合一个语境,那么在这之前,你至少要做一次彻底的线上调研,看看是否已经有工业和事实标准存在。

我就曾经见过一位研发人员自己定义了一套国家码。他一口气整出来240多个国家,胆子可真大!

小结

所谓统一语义,并不是要求你重新学习一门标准化的语言,然后再跟其他参与者交流。统一是语义层面的统一。

你作为架构师,所做的工作并不是收集汇总,而是发现不同的语境,找到其中存在的语义上的差异。然后把这些差异描述出来,再给出一个精确的语义定义。最后再和其他参与者一起使用这些更为准确的概念,来完成项目的规划和实施。这才是你在这个节点上真正要创造的价值。

在统一语义的的过程中,你要努力发现整个架构活动中所有不同角色。然后以客观事实、无损的表达和最小化沟通为目的来和他们沟通,从而统一语义。当你能邀请大家到同一个语义环境下做深度讨论的时候,我相信那将会是一个非常美妙的聚会,因为那才是灵魂之间的深度交流!

另外,这两节课我们花费了比较多的篇幅去分析和寻找语义分歧问题的根源。这也是架构师的一个基本技能。其实大多数时候,找到了问题的根因也就找到了解法。

从更深层次上来讲,寻找根因这个方法论也适用于我们整个架构规划。我们之所以要在统一语义这个环节下大功夫,目的就是在定义“我们要解决的问题”上帮助所有参与者达成共识,一起找到那个真正值得耗费大家生命力的 “问题根因”!

思考题

三个作业,任选一个来作答。

  1. 你见到过最清晰的领域建模是哪一个?这个模型最终带来了什么样的价值?
  2. 领域建模是为了定义我们要解决的问题。很多人号称自己在做领域建模,但往往是代码都写完了去晋升的时候才做。不过,哪怕这么做往往也有价值。你做过这种事后的建模吗?建模帮助你发现了什么问题?
  3. 建模的习惯一旦养成了,应用起来还是比较高效的。但是紧接着就会出现模型管理的问题。你碰到过什么好的模型管理的方法吗?不好的呢?

标签:25,架构,语境,角色,不同,语义,郭东白,分歧,定义
From: https://www.cnblogs.com/gongxianjin/p/16989174.html

相关文章

  • 郭东白的架构课24
    你好,我是郭东白。从这节课开始,我们就进入到架构活动的第四个环节——架构规划。这个环节比较复杂,可以分为四个部分:统一语义、需求确认、边界划分和规划确认。这节课我们先......
  • 郭东白的架构课28
    你好,我是郭东白。上节课我们讲了任务边界划分的五个核心信条,可以作为任务划分与调整时的策略依据。那么实际工作中应该怎么运用呢?这节课我们就来聊聊这个问题。任务梳理和......
  • 郭东白的架构课29
    你好,我是郭东白。这节课我们来讲架构规划的最后一个环节——规划确认。在上节课,我们已经梳理出了一组必保需求,然后从这组需求中推导出了一组任务。并且,我们以最大化某个项......
  • MVC、三层架构、数据库连接池、Spring JDBC
    MVC模式MVC全名是ModelViewController,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻......
  • 2022年架构设计师考试
    考试时间:2022.11.05分数:57/59/47(2022.12.15)疫情三年(2020-2022,第一次开考架构设计师,前几次都是因为疫情取消了)终于能考了。感谢北京政府让这个考试能顺利进行,要不然又要等......
  • MPP架构与Hadoop架构是一回事吗?
    计算机领域的很多概念都存在一些传播上的“谬误”。    MPP这个概念就是其中之一。它的“谬误”之处在于,明明叫做“MassivelyParallelProcessing(大规模并行处理)”,却让......
  • 一文了解 Dubbo 的代码架构
    整体设计图例说明:图中左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。图中从下至上分为十层,各层均......
  • 一文了解 Dubbo 的代码架构
    整体设计图例说明:图中左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。图中从下至上分为十层,各层均......
  • 一文了解 Dubbo 的代码架构
    整体设计图例说明:图中左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。图中从下至上分为十层,各层均......
  • 【《硬件架构的艺术》读书笔记】06 流水线的艺术(2)
    6.6DLX指令集的实现这节开始将指令集相关内容,没学过相关知识,看不太懂,就快速浏览一下好了。DLX指令集包括五个部分:1、指令获取(IF)IR<=MEM[PC]NPC<=PC+4从存储器......