事件存储设计指南

事件溯源里，存储层往往被低估

聚合状态可以重建，但前提是事件流持久化可靠：只能追加、按流有序、能版本冲突检测，还要支撑订阅与重复写入。团队在选型 EventStoreDB、PostgreSQL、Kafka 或 DynamoDB 时，常见问题不是「能不能存」，而是查询模式、乐观并发和模式演化是否与业务一致。

技能如何组织设计工作

本技能把设计拆成可执行的步骤：先明确目标、约束与输入，再对照核心需求表（仅追加、有序、版本化、订阅、幂等）校验方案，并给出技术对比与验证要点。

• 架构与需求：区分按流排序与全局排序，从第一天做事件版本控制
• 实现模板：PostgreSQL 表模式、Python 实现、EventStoreDB、DynamoDB 等参考路径
• 最佳实践：流 ID 含聚合类型（如 Order-{uuid}）、关联/因果 ID、按查询模式建索引；避免更新/删除事件、巨型 payload、跳过 OCC 或忽略背压

更细的示例见 resources/implementation-playbook.md。

适用边界

任务与事件存储设计无关，或需要完全另一套领域/工具时，不必启用本技能。Kafka 适合高吞吐流处理但不适合按流查询；Marten 绑定 .NET；PostgreSQL 等需在现有栈上手动实现事件存储语义。