Event Storming中使用"xxx Requested"类Domain Event是否为合理实践？

这类以Requested结尾的橙色便利贴属于合规的可选实践，不存在原则性错误，是否使用完全取决于业务场景的复杂度，不需要为了避免便利贴数量翻倍就完全否定它的价值。

核心合理性依据 #

领域事件的核心定义是「领域中已经发生的、对业务有影响的客观事实」，XXX Requested本质上记录的是「业务请求已经被系统接收」这个已经发生的事实，完全符合领域事件的定义，不是错误用法。

这类事件的核心价值 #

• 明确区分「意图发起」和「意图落地」两个业务阶段的边界，完整覆盖分支逻辑。比如Create Account Requested提交后，系统可能触发手机号查重、黑名单校验等规则，校验不通过就不会生成Account Created事件，如果没有请求类事件，就没办法在事件风暴中体现「注册申请被驳回」这类异常分支的业务流程。
• 清晰梳理跨限界上下文的协作依赖。比如Order Cancellation Requested可能是用户在订单上下文发起的，后续需要和支付上下文确认退款完成、和仓储上下文确认发货拦截成功，所有校验通过后才会生成Order Canceled事件，请求类事件可以把多上下文的协作逻辑完整串起来，不会漏掉中间的处理环节。
• 为后续业务可观测性、审计需求提供设计依据。如果业务要求留存所有操作请求的记录（不管成功失败），或者需要快速定位操作故障的发生节点，请求类事件可以直接对应到埋点、日志的设计需求，减少后期技术设计的遗漏。

适用场景 #

只有符合以下特征的场景才推荐使用，避免不必要的冗余：

• 请求提交和最终落地之间存在异步延迟、多步骤业务校验
• 请求存在被业务规则拒绝的可能性
• 请求需要跨多个限界上下文协作完成
• 业务有合规审计要求，需要留存所有请求的操作记录

如果是同步处理、无校验逻辑、提交即可成功的简单操作（比如无库存限制的加购操作），完全不需要添加请求类事件，直接保留最终的结果事件即可，强行使用反而会增加事件梳理的复杂度。

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