基于DDD的实时协作CAD可视化：批量操作与复合模式建模问题

问题背景 #

正在用领域驱动设计（DDD）建模实时协作应用，核心是CAD可视化功能，遇到两个事件粒度与批量操作建模的困惑：

问题1：用户偏好批量修改的事件设计 #

多名参与者加入3D虚拟环境，其中一名为协调人：

• 所有参与者可自行修改个人偏好
• 协调人能批量修改所有用户偏好，用户也可单独改回
  当前困惑：批量操作应提交粒度事件（每个用户的偏好修改事件）还是单一批量事件？现有流程仅监听粒度事件，若用批量事件会被遗漏；若只用粒度事件，又破坏领域边界的清晰性。

问题2：CAD结构显隐操作的事件设计 #

CAD模型元结构为DAG：

• 叶节点是可共同操作的三角形组（Volume）
• 多个Volume构成Branch，Branch可包含子Branch，Branch+Volume形成树结构
• 不相交的树分支构成Group
  参与者可设置Branch/Group/Volume的显隐，困惑：应发布单一Branch/Group级事件，还是为路径上每个Branch/Volume发布事件？

已有尝试的痛点 #

• 曾考虑在同一主题下同时发布批量和单一操作的对应事件，但新增批量事件可能影响下游上下文
• 曾尝试同时发布带correlation_id的批量与粒度事件，让下游忽略同ID的后续事件，但存在并发处理时的顺序混乱问题

DDD视角下的解决方案 #

针对问题1：用户偏好批量修改的建模 #

1. 明确聚合根边界
   • 将「用户偏好」作为独立聚合根，每个用户的偏好属于自己的聚合；而「协调人批量操作」属于协作会话聚合根的行为。
   • 协调人触发批量修改时，由协作会话聚合根发布UserPreferencesBatchUpdated事件，事件携带批量操作的上下文（比如操作发起者、修改的偏好项、目标用户范围）。
2. 下游上下文的适配处理
   • 若下游依赖原有粒度事件，可在领域事件网关中做转换：监听UserPreferencesBatchUpdated事件，拆解为单个用户的UserPreferenceUpdated事件分发，但需给这些拆解的事件标记batch_operation_id，避免与用户主动修改的事件混淆。
   • 核心原则：领域事件要贴合领域语义——批量修改是一个明确的领域行为，不能为了适配下游而牺牲领域模型的清晰度，下游的适配应该放在基础设施层或上下文映射层处理。
3. 用户单独改回的冲突处理
   • 在用户偏好聚合根中添加last_updated_by和update_source（区分「用户主动修改」/「协调人批量修改」），当用户单独改回时，发布UserPreferenceUpdated事件并标记为用户主动操作，下游可根据update_source优先处理用户主动操作的事件。

针对问题2：CAD结构显隐操作的事件设计 #

1. 基于聚合根的事件发布
   • 先明确CAD结构中的聚合根：将Group、Branch作为独立聚合根（因为它们是可被独立操作的领域对象），Volume属于Branch聚合根的子实体。
   • 当操作Branch的显隐时，由Branch聚合根发布BranchVisibilityUpdated事件，事件携带Branch ID、可见性状态、操作发起者；同理，Group操作发布GroupVisibilityUpdated事件，Volume操作发布VolumeVisibilityUpdated事件。
2. 避免递归事件的冗余
   • 若Branch的显隐会递归影响子Branch和Volume，这个逻辑应放在应用层或基础设施层的投影处理中，而非领域层发布大量子节点事件。比如下游的可视化投影服务监听BranchVisibilityUpdated事件后，自行递归处理其下所有子节点的状态更新，无需领域层发布每个子节点的事件。
   • 领域层只需要表达「修改Branch显隐」这个核心领域行为，递归影响是技术实现细节，不应污染领域事件的语义。

通用批量操作的DDD复合模式 #

1. 复合事件模式
   • 对于批量操作，可发布一个包含操作元数据（correlation ID、操作范围、发起者）的复合事件，同时在事件中包含每个被修改对象的变更明细。比如UserPreferencesBatchUpdated事件结构：

     {
       "correlation_id": "batch-123",
       "initiator_id": "coordinator-456",
       "updated_users": [
         {"user_id": "user-1", "preferences": {"theme": "dark"}},
         {"user_id": "user-2", "preferences": {"theme": "dark"}}
       ]
     }
     

   • 下游上下文可根据自身需求选择：要么直接处理复合事件，要么拆解为单个事件处理，无需额外的事件转换层。
2. 事件溯源中的批量操作处理
   • 若采用事件溯源，批量操作的事件应作为一个单独的事件存入事件流，而非多个粒度事件。这样在重建聚合状态时，可一次性处理批量操作，避免事件流冗余。
   • 为了兼容下游的粒度事件依赖，可在读模型投影中处理复合事件，生成对应的粒度事件投影，而非修改写模型的事件结构。

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