DDD：不同上下文下实体基数差异建模及重复实体问题咨询

一、先明确两个上下文的核心差异 #

别被同名迷惑，配置层和运行时的Task/Sub-Task本质是不同职责的概念：

• 配置层的Task是任务模板：用来定义可被实例化的任务蓝图，包含多个可选子任务模板，核心是「规则定义」，生命周期是创建、修改、发布。
• 运行时的Task是执行实例：是模板的具体落地，绑定了用户选定的唯一子任务，核心是「执行跟踪」，生命周期是创建、执行、完成/终止。

二、解决重复实体的具体方案 #

1. 引入共享内核（Shared Kernel） #

把两个上下文通用的核心元素抽成共享模块，避免重复定义：

• 定义TaskId、SubTaskId作为值对象，确保跨上下文的ID语义一致（运行时Task的ID直接引用配置层模板的ID）
• 抽取出通用业务规则，比如「Sub-Task必须隶属于对应Task」的约束，放在共享内核里统一维护

之后在两个上下文里分别扩展专属实体：

• 配置层：ConfiguredTask（实体），关联List<ConfiguredSubTask>（实体，包含子任务的配置属性，比如执行逻辑、默认参数）
• 运行时：RuntimeTask（实体），关联SelectedSubTask（值对象，仅保留执行所需属性，比如SubTaskId、用户自定义参数）

2. 用上下文映射（Context Mapping）实现解耦依赖 #

如果不想用共享内核，可通过防腐层（ACL）或事件发布订阅同步必要信息：

• 配置层在模板发布时，抛出TaskTemplatePublished事件，携带TaskId、可用SubTask列表等核心数据
• 运行时通过防腐层接收事件数据，在创建RuntimeTask时，验证用户选择的SubTask是否属于对应模板的可选范围

这种方式下两个上下文的实体完全独立，通过映射保证数据一致性，避免重复定义业务规则。

3. 收缩实体边界，区分实体与值对象 #

• 配置层的ConfiguredSubTask是实体：它有独立的配置属性，且属于对应ConfiguredTask的专属集合，具备独立的修改生命周期
• 运行时的子任务不需要作为实体：可设计为SelectedSubTask值对象，完全依附于RuntimeTask，只记录执行必要的标识和参数，无需独立生命周期

三、核心原则 #

DDD建模的关键是按业务职责划分边界，而非按名称归类。配置层的「模板」和运行时的「实例」行为、生命周期、属性都不同，本就不是同一实体，只是名称重合而已，理清这一点就不会陷入重复定义的误区。

内容的提问来源于stack exchange，提问作者damike