6.16本体论圆桌 关于6个问题的思考

问题1、在领域驱动设计（DDD）中，我们常说建立“通用语言”。但在微服务拆分时，“订单”、“用户”、“商品”在不同子域里的定义截然不同。请问各位，在软件架构中，我们究竟应该追求一个“唯一的、客观的全局本体”，还是坦然接受“按上下文分裂的多重实在”？强行统一是不是架构灾难的根源？

个人观点：我认为，要想真正做到和追求一个“唯一的、客观的全局本体”是非常困难的，尤其项目越大，组织越割裂，如果强行统一，虽然表面上看起来更整洁，但往往会把业务差异、组织差异和演化差异压扁，最后导致沟通成本上升、耦合加重。所以，我个人的观点是倾向于在局部上下文内追求本体统一即可，在跨上下文时，做好本体间的映射，做好本体映射的数据字典，让本体通过这种方式进行对齐和具备可解释性。所以整体架构设计上，所追求的硬应该是【局部真理】。

问题2、传统关系型数据库要求“先有Schema（模式）再有数据”，这像极了古典哲学的先验论；而NoSQL和数据湖的“读时 Schema”则更像存在主义——数据先在那里，你再赋予它结构。在如今的AI驱动下，我们是否已经到了必须抛弃“Schema-on-Write（写入时建模）”的时代？如果数据没有预定义结构，它算不算“存在”？

个人观点：无论是关系型数据库还是非关系型数据库还是向量数据库，都是时代和业务发展下的产物。不同的数据类型和结构决定了是先有鸡还是先有蛋的问题，没有绝对的对错，但无论哪种，我认为进行必要的结构化约束是特别重要的。先来说说Schema-on-Read，也就是上面提到的读时Schema，它的优势在于灵活，适合探索性分析、日志、半结构化数据和快速迭代；而Schema-on-Write的优势则是在于一致性、质量控制、可治理性和下游的稳定性。所以最后再来说说AI驱动下的数据，从表面看，看似消除了数据结构的价值，抛弃了Schema-on-Write，但是这种建模方式是无法保证数据的稳定性、可治理性与可审计性，所以，在其上层必须再叠加一个结构化建模，两者彼此相结合互补。整体来看，底层可以保留原始数据和较宽松的数据管理方式，但在上层的关键业务域里需要做严格建模。

问题3、我们把一切文本、图像、代码都压缩成高维向量（Embedding）。这个向量空间里的“距离”和“方向”成了新的“关系”。我想请教AI专家：当我们说模型“理解”了某个实体时，这个实体在神经网络里的“本体”到底是那串浮点数，还是训练数据里原文的痕迹？如果向量空间能完美推理，我们还有必要维护传统的知识图谱（显式本体）吗？

个人观点：大模型时代，Embedding确实改变了我们存储和读取知识的方式。这里的第一个小问题，实体在神经网络里的“本体”，既不是那串浮点数，也不是训练数据里原文的痕迹，而是浮点数所编码出来的分布式语义结构，原文痕迹只是训练来源，真正起作用的是参数化后的表示。而第二个小问题，知识图谱与向量空间是互补的，不是替代的关系。向量可以增强推理；知识图谱则擅长显式关系；二者本质和定位就不同。所以业界的做法是组合使用，向量负责感知，图谱负责约束，规则负责确定性。

问题4、在分布式架构中，“事件溯源（Event Sourcing）”把“状态”视为“事件流”的副产品。这直接颠覆了“状态是本体”的常识——如果“订单已支付”这个事件比“订单”这个实体更真实，那我们的架构是否应该把“变化（事件）”而非“静止（表）”作为第一性本体？这对缓存和一致性协议意味着什么？

个人观点：本体是本体，属性是属性，事件就是事件，所以首先要先搞清楚三者的关系，不要混淆和组装后包装成新概念，我相信现在也没有哪个架构师会把“变化（事件）”而非“静止（表）”作为第一性本体。再来说说事件溯源（Event Sourcing）中缓存的定位，如果事件是事实来源，那么缓存只是事件驱动下的派生物，一致性协议也会从【强一致性】更多转向【最终一致性 + 补偿机制】

问题5、上下游系统通过API契约（如ProtoBuf/JSON Schema）耦合。当上游要修改“用户ID”类型，从String改为Long时，这就是一次“本体论革命”。在组织层面，这种变更往往引发跨部门争吵。各位认为，决定系统“根本存在结构”的权力，应该掌握在提供方（生产者）、消费方（使用者）还是中间的平台架构组手里？

个人观点：这件事其实挺复杂，因为它不是一个技术问题，本质上是一个组织、文化和责任边界的问题。我说一下我认为合理的做法：生产者负责制定契约和发布，消费者负责做兼容性反馈，平台架构组负责规范、治理和仲裁。所以，不能说但由某一方决定，因为如果只由生产者决定，容易忽略下游真实成本；如果只由消费者决定，上游则会失去演进空间；如果完全交给平台架构组，则又容易脱离业务现实。所以还是要制定好规则和变更评审机制，生产者对向后兼容负责，消费者对及时适配负责，平台对规则和治理负责。

问题6、现在AI能写代码、能设计数据库表，甚至能提出微服务拆分方案。如果未来AI自己维护一套用于描述“软件架构”的本体（比如它自定义的Maven坐标或K8s资源定义），而人类已经看不懂这套本体的含义，但系统跑得又快又好——这是不是意味着我们进入“算法本体论”时代？届时工程师的职责，是否要从“定义存在”退化为“监管存在的涌现”？

个人观点：客观来讲，从AI的发展趋势来看，这种情况是有可能出现的，尤其从老板的思维来看，是希望看到这种结果的，因为毕竟人工的成本要比Token贵很多吧，而且我相信以后Token会越来越便宜。但是呢，你要说完全AI化是不可能的，肯定是需要工程师去整体“控制”AI，所以这就涉及到未来工程师的职责，我认为更应该侧重于【定义目标、约束边界、设定规则、审查结果和最重要的一点，掌控AI】。现在，工程师的职责，已经从软件的直接建造者，变成了软件的设计人员、监督人员和治理人员。尤其随着系统越来越复杂，包括对已有系统也是一样，肯定不能单纯只靠人去把控所有系统细节，而是应该是由AI主导系统，在你的“控制”下，在可控边界范围内，让系统自生长。