业务抽象与数据语义的本质

写了这么久的代码，一些思考感悟。

一、抽象的本质问题

业务抽象可以带来代码复用，但会被特例冲垮。根本原因不是特例没被纳入抽象范围，而是抽象边界划定错了——把本质不同的东西强行归为同类，把不同的变化轴混在了一起。

二、逻辑分叉的树形本质

世界上任意事物都可以用树形结构描述，逻辑的分叉本质上是区分凭证不同而已。凭证提取自元数据。

三、元数据的分类方式应该是计算出来的

既然凭证来自元数据，就应该先通过类似 NLP 的思想将元数据进行 embedding，计算相似度，再通过无监督学习抽象出元数据特征，从而针对性地分类描述——而不是人工预先定义分类边界。

四、共有特性可以从数据产生链路中描述

数据的共有特征一定可以从数据产生的链路中描述出来。链路携带了因果信息，同一条链路产生的数据天然共享前置条件、约束范围和语义上下文。

五、描述阶段不应注入语义

描述事物特征应该使用 code 编码，而不应该在描述阶段就用定义来分类做语义化。语义本身携带分类特性，在描述阶段过早注入语义，会把当前认知的局限固化进数据结构。

六、语义体现在数据共性上

语义不应该是人为命名时注入的，而应该从数据的共性模式里自然浮现。语义体现在数据共性上，而不是停留在语义描述上。

七、数据的语义由场景赋予

数据永远是流动的，流动到哪个场景就会被赋予场景相对应的实际意义。语义不是数据的属性，而是数据与场景关系的属性。

因此系统设计上应该是：

• 数据层：忠实记录，使用中性编码，不做语义判断
• 场景层：接收数据，按自身上下文解释意义

两层之间的耦合只有结构，没有语义。场景变化不会反向污染数据层，数据层的抽象因此保持稳定。