代码之家 › 专栏 › 技术社区 › WHITECOLOR

活动来源:非商业重要活动

event-sourcing

WHITECOLOR · 技术社区 · 7 年前

这是关于ES的一般架构问题。人们通常担心的是需要保留大量影响中间状态的业务非重要事件,尽管我们最终肯定不会关心它们(只会忽略它们)。

假设我们有一个用户,它有一个项目列表(即任务),用户可能经常添加/删除/编辑任务的不同字段。例如,如果我们正在构建ES,我们应该将每个更新视为一个单独的事件 TaskNameChange , TaskCommentChange 等等,或者我们可能有一个活动 TaskModified 无论什么是不是我们从任务更改历史中得不到太多,从业务角度来看,我们只关心最后一个(例如最后一个) 任务名称更改 ),但无论如何,我们应该跟踪并记录所有事件。

我再次担心的是,我们应该在活动商店中记录并保存大量没有商业意义的事件。

有人遇到过这样的情况吗?对此有什么想法?

1 回复 | 直到 7 年前

VoiceOfUnreason 7 年前

有人遇到过这样的情况吗?对此有什么想法?

赛马场

如果与保留文档的完整事件支持历史记录相关的成本超过了您可以从该历史记录中获得的业务价值,那么不要将系统设计为保留所有历史记录。设置文档存储,每次保存时覆盖文档的早期版本,然后继续操作。

格雷格·杨: a whole system based on event sourcing is an anti pattern .

推荐文章

Jordi · 事件源:处理事件架构更改

6 年前

engma · 事件来源中的事件消费者和重复代码

6 年前

WHITECOLOR · 活动来源:非商业重要活动

7 年前

inf3rno · 事件源-删除事件相关文件

7 年前

user3139545 · 理解具有数据流的持久实体

7 年前

user8280126 · 事件源/CQRS聚集索引和分区

7 年前

Jim Aho · 我应该继续添加事件吗?

7 年前

codependent · Spring Kafka-事件源-如何使用Kafka+KafkaStreams API查询某些实体状态的示例

7 年前

Roshan · 如何使用CQRS和事件源处理依赖于应用程序中现有记录的命令

8 年前