从DDD到Ontology：当数字员工不再认"限界上下文"这堵墙 - 张善友
内容提要
本文探讨了DDD在数字员工时代的局限性。DDD主要解决人与代码间的语义一致性问题，但无法应对机器执行时的语义歧义，导致数字员工对“新增有效客户”等概念理解错误。文章提出在DDD之上增加Ontology语义层，作为机器可读的运行手册，以解决跨边界语义统一和精确表达问题。
延伸解读
DDD的边界：从保护墙到认知盲区
文章指出，DDD的限界上下文原本是保护系统复杂性的墙，但在数字员工执行任务时，这堵墙反而成了认知盲区。数字员工不读文档、不遵守上下文映射，导致跨边界的语义冲突。例如，物流和财务对“订单”的不同理解，在人类协作中可通过沟通解决，但数字员工只会机械执行，从而产生系统性错误。这提醒我们，当执行主体从人变为机器时，原本依赖人类默契的边界机制需要重新设计。
语义层不是单一解决方案
案例中，不同团队对“语义层”的理解各不相同：BI团队认为是事实表维度表，指标团队强调统一口径，数据治理团队关注元数据，AI团队需要同义词和歧义规则。这说明语义层并非一个简单的技术组件，而是需要多维度协同的体系。文章提出的Ontology作为机器可读的运行手册，试图整合这些需求，但实际落地时仍需明确各团队的职责与协作方式，否则“语义层”只会成为又一个概念空转。
从设计时建模到运行时建模的转变
DDD的领域模型是设计时的静态产物，假设模型在编码前已确定。但数字员工的工作方式是运行时建模，在生成代码过程中动态调整对领域的理解，导致“执行偏差”。文章认为，Ontology作为运行时的活领域模型，能通过“定义→执行→反馈→修正”的闭环适应这种动态性。这提示我们，在AI时代，业务建模可能需要从静态文档转向持续演化的机器可读规范，以匹配数字员工的执行特性。
Q&A
DDD在数字员工时代面临哪些局限性？
DDD主要解决人与代码之间的语义一致性问题，但在数字员工时代，它无法应对机器执行时的语义歧义，导致数字员工对业务概念理解错误。具体局限性包括：不解决跨Skill的语义统一、不解决数字员工的可执行性问题、不解决业务规则的精确表达问题。
为什么数字员工会误解“新增有效客户”这类业务概念？
因为DDD没有定义“新增有效客户”的精确语义，相关规则分散在代码、文档或业务人员脑中，没有形成机器可读的语义契约。数字员工只能根据字段名和统计相关性理解，导致理解偏差。
Ontology在数字员工时代扮演什么角色？
Ontology作为DDD之上的一层语义契约，是机器可读的运行手册，用于解决跨边界语义统一和精确表达问题，使数字员工能够直接读取业务定义并执行操作。
DDD和Ontology在解决语义一致性问题上有什么不同？
DDD解决的是人和代码之间的语义一致性问题，而Ontology解决的是人和机器之间的语义一致性问题。DDD的载体是代码，Ontology的载体是平台；DDD是设计时的静态快照，Ontology是运行时的活领域模型。
为什么说DDD的限界上下文在数字员工时代变成了认知盲区？
因为限界上下文是给人画的墙，数字员工不认墙，它只认Prompt中的指令和训练数据中的模式。数字员工不读领域文档，不理解上下文映射，也不会主动使用防腐层，导致跨边界语义混淆。
数字员工的执行偏差（Execution Drift）是什么？如何产生？
执行偏差是指数字员工在运行时动态建模，导致设计时的静态模型无法约束运行时的动态生成，从而产生行为偏差。产生原因是数字员工的工作方式是运行时建模，它在生成代码过程中不断调整对领域的理解，而DDD的领域模型是设计时的产物。
在数字员工时代，领域模型的作用发生了什么变化？
过去领域模型是连接业务和代码的翻译层，依赖人类理解和协作。现在数字员工不需要这座桥，它直接从Ontology读取业务定义并执行操作，因此Ontology不再是设计时的参考文档，而是运行时的操作手册。
