对于简单的增量表单更新来说，事件溯源是否过大？答案

【问题标题】：Is event sourcing an overkill for simple incremental form updates?对于简单的增量表单更新来说，事件溯源是否过大？
【发布时间】：2021-10-04 02:19:08
【问题描述】：

我正在开发一个在事件溯源中实现后端的网络应用程序。事件溯源使我们能够及时回溯，运行预测以获取不同类型的报告。此外，如果需要，我们可以通过重播投影从头开始构建我们的数据库。

我们的某些模块通过在其中实现事件溯源并没有提供太多分析价值。例如，创建问卷，这不过是一个简单的表格 CRUD。我们有事件溯源，但我们可能从中获得的唯一优势是从存储的域事件中重建表单数据库。或者获取诸如用户填写问卷所花费的时间等值。

但这些分析仍然没有给我们提供太多信息，因为表单中的状态变化不如系统的其他部分有价值。就像例如与更改表单 CRUD 的状态相比，通过域事件更改银行帐户的状态为我们提供了更多信息。

你们如何处理这种情况并知道应用程序的某个部分是否适合事件溯源或是否过度杀伤？

【问题讨论】：

【解决方案1】：

它是否矫枉过正是一个见仁见智的问题，但 CRUD（或真正的 CUD，因为读取不是一个有意义的事件）事件（例如 WidgetCreated、WidgetUpdated、WidgetDeleted；尤其是 @987654324 @) 可能是一个贫血域的标志。

假设每次更新在您的数据库中都是原子的，您可以通过使用更改数据捕获（例如，许多 SQL 数据库将更改提要放入Kafka 主题或 Azure Cosmos 等一些数据库提供本机更改源）以捕获对数据库中记录的更改。

现在使用 CUD 事件进行事件溯源确实可以让您在以后需求发生变化时灵活地充实域模型。这需要了解需求发生变化的可能性（以及何时......），以使更丰富的领域事件变得方便，而不是您现在在事件溯源方面花费了多少精力。

【讨论】：

谢谢@Levi，这更有意义，并为看待这种情况提供了新的视角。使用 Debezium 作为事件的产物是一个好主意。我将在白板上编写域逻辑并查看模型需求被更改的可能性。