使用Prooph能否自定义设置事件的created_at时间以处理延迟采集的指标数据？

这个需求完全可以通过Prooph实现，且完全符合事件溯源的设计逻辑，事件溯源本身就支持业务事件发生时间和系统写入时间分离的场景。

• 自定义事件的时间属性：Prooph的DomainEvent支持自定义扩展字段，你可以给状态变更事件添加occurred_at字段，用来存储业务侧的真实发生时间，比如你示例中10:23的OFF事件，就可以将occurred_at赋值为2021-11-08 10:23:00，该字段会和事件载荷、元数据一起持久化到Event Store中，不受实际写入时间（10:30）影响。
• 自定义时间索引：如果你需要基于真实发生时间做事件排序、投影计算或者时序查询，可以将occurred_at配置为Event Store的元数据索引，后续做聚合状态重建、业务逻辑判断时都可以基于该字段处理，不用依赖存储默认的写入时间戳。
• 批量事件写入适配：你可以先对拉取到的批量指标做去重处理，仅在setting值发生变更的时间点生成对应的领域事件，给每个事件设置对应时间的occurred_at值后，批量写入Event Store即可，处理逻辑示例如下：

// 示例伪代码
$lastSetting = null;
foreach ($metrics as $metric) {
    if ($metric['setting'] !== $lastSetting && $lastSetting !== null) {
        $event = match($metric['setting']) {
            'on' => new SettingTurnedOn(occurredAt: $metric['time']),
            'off' => new SettingTurnedOff(occurredAt: $metric['time'])
        };
        $eventBus->dispatch($event);
    }
    $lastSetting = $metric['setting'];
}

• 严格区分两类时间属性，不要混用：
  • 业务发生时间：领域事件的固有属性，所有业务逻辑、状态重建、投影计算都应该以该时间为准
  • 系统写入时间：事件持久化的技术属性，仅用于运维排查、延迟统计等技术场景
• 如果存在实时事件和延迟事件同时写入的场景，在投影处理层需要基于occurred_at做事件重排，不要依赖Event Store的默认写入顺序，避免业务时序错乱。
• 如果聚合需要做事件一致性校验，校验逻辑要基于occurred_at判断事件先后顺序，避免因写入延迟导致的校验误判。

如果你的场景不需要Prooph提供的CQRS、聚合状态管理等能力，也可以先用时序数据库存储原始采集指标，仅将状态变更事件同步到事件存储，降低批量处理的复杂度。

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