DDD与事件溯源设计：冗余事件识别及InvestorAccountCreated选型

核心结论 #

当前业务阶段完全不需要保留InvestorAccountCreated事件，不要为了不确定的未来需求提前做冗余设计。

具体判断依据 #

判断一个聚合的创建类事件是否有必要存在，核心看三个维度，和不确定的未来扩展没有关系：

• 第一，事件是否对应独立的、真实发生的领域行为。事件溯源里的所有事件都必须是业务侧真实发生的事实，不是为了凑技术流程人为造出来的节点。你当前业务规则里根本不存在「完成开户但无任何持仓」的独立环节，投资者首次买入股票就是账户生命周期的起点，首笔SharesBought事件本身就承载了「账户正式生效」的事实，单独拆出一个创建事件属于脱离业务的技术自嗨。
• 第二，事件是否承载其他事件无法覆盖的独有业务信息。如果后续业务真的演进到需要独立开户流程——比如要求用户先完成风险测评、绑定存管账户、开通对应市场交易权限才能发起交易，那开户动作本身会产生一堆专属信息：开户渠道、风险等级、账户权限、开户经办节点、专属服务关系等等，这些信息根本没法塞进SharesBought事件里，到那个阶段再加InvestorAccountCreated事件完全不晚，事件溯源的事件流天生支持演进，根本不需要提前占坑。
• 第三，去掉该事件后是否会增加聚合逻辑的复杂度。如果不设创建事件，聚合重建时只需要加一层简单判断：若事件流首个事件为SharesBought，直接初始化空账户实例再应用持仓变更逻辑即可，和有创建事件的重建流程比，没有额外的状态歧义、没有逻辑分支冗余，就完全没有必要多增加一层事件包装。

冗余事件的识别方法 #

你可以通过三个标准快速排查设计里的冗余事件：

• 看事件有没有独立的触发源。如果一个事件永远不会被用户操作、外部系统回调、定时任务等场景单独触发，必须依附另一个事件同步生成，那大概率是冗余的。比如当前场景下如果InvestorAccountCreated永远跟着第一笔SharesBought生成，没有单独触发开户的业务入口，它就符合冗余特征。
• 看事件有没有独有的业务属性。如果一个事件除了聚合ID、事件时间、操作人这类通用元数据外，没有任何专属的业务字段，所有承载的信息都能被依附的主事件完全覆盖，那就是冗余的。
• 看删除事件后是否会产生逻辑缺口。如果删掉这个事件之后，聚合状态重建、业务规则校验、下游事件消费的所有逻辑都能正常运行，没有信息缺失、没有规则冲突，那这个事件就没有存在的价值。

别拿「未来可能需要」当冗余事件的挡箭牌。事件溯源的历史数据兼容成本极低：真到了需要独立开户的阶段，你只需要给新生成的账户加上InvestorAccountCreated事件即可，完全不需要回填历史数据。只需要在聚合重建逻辑里加一层兼容：如果事件流第一个事件是SharesBought，就按老规则初始化账户；如果第一个事件是InvestorAccountCreated，就按新规则先加载开户信息再处理后续交易事件，不会有任何兼容性问题。提前加没用的事件，只会徒增事件存储成本、让聚合逻辑变臃肿，后续还要多维护一类永远不会单独触发的事件，纯负收益。

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