胖/瘦领域事件选型：Question聚合场景下如何选择合适的领域事件发布方案

一、创建问题场景的事件选型 #

针对你提到的两种方案，合理性判断和适用场景如下：

第一种方案：发布单一QuestionCreated事件 #

你当前的事件定义：

public class QuestionCreated {
  private final String questionText;
  private final List<Answer> answers;
}

这个设计不存在本质问题，唯一需要调整的是不要直接把聚合内部的Answer实体类作为事件属性，应该转成只读的、事件专属的值对象结构，避免泄露聚合内部实现细节，也防止外部意外修改实体状态。
该方案的适用场景：

• 没有独立的下游逻辑需要单独感知「问题创建阶段生成的单个答案」
• 下游消费QuestionCreated事件时，只需要整体获取问题创建时的完整信息即可

第二种方案：拆分发布QuestionCreated+ 多个AnswerCreated事件 #

该方案本身是合理的，但是有前提约束：

• 业务存在独立的下游消费场景，比如答案内容审核、单答案计数统计等，需要不管答案的生成场景，统一感知单个答案的生成
• 必须保证事件发布顺序：QuestionCreated早于所有同批次的AnswerCreated，且每个AnswerCreated必须携带所属的问题ID、以及「初始化答案」的场景标识，避免下游混淆答案是创建问题时生成的，还是后续新增的
• 所有事件必须在同一个事务内完成发布，保证状态一致性

二、新增答案场景的事件选型 #

优先选择仅携带新增答案信息的AnswerAdded事件，不要使用全量QuestionUpdated事件，原因如下：

1. 语义精准：事件本身就可以直接表达「给指定问题新增了一个答案」的业务动作，下游不需要额外比对数据判断变更类型
2. 效率更高：事件仅携带问题ID、新增答案内容、操作时间等必要信息，传输、解析成本远低于全量事件
3. 降低下游逻辑复杂度：下游不需要对比新旧全量数据识别变更点，避免比对逻辑出错的风险

仅当存在下游强依赖问题的完整最新状态，且没有对应细粒度事件可以覆盖需求时，才考虑补充全量更新事件，该场景在实际业务中非常少见。

通用选型原则 #

• 优先选择语义最贴合业务动作的细粒度事件，避免用粗粒度全量事件兜底
• 事件仅携带下游消费需要的公共信息，不要暴露聚合内部的实现细节
• 同一个业务操作触发的多个事件，必须保证发布顺序和业务发生顺序一致，且纳入同一个事务管理，保证要么全部发布成功要么全部失败

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