事件溯源和导入平面/XML 文件答案

【问题标题】：Event Sourcing and Importing Flat/XML Files事件溯源和导入平面/XML 文件
【发布时间】：2017-10-30 23:53:52
【问题描述】：

我在一家金融公司工作。我们收到了数百万个平面文件和 xml 文件并导入 SQL 服务器数据库，在这个特定系统中没有 Api 数据。

是否应该为这种类型的系统使用事件溯源，将平面文件 ETL 导入数据库？我一直认为 Event Sourcing 更多地用于前端 Web 应用程序，因此我们可以跟踪所有数据，并将事件重播到读取模型中。

谢谢，

【问题讨论】：

【解决方案1】：

是否应该为这种类型的系统使用事件溯源，将平面文件 ETL 导入数据库？

拿别人的平面数据，并试图从“事件”中提取出来，在我有限的经验中是愚蠢的差事。

通过记录所有事件的历史记录来跟踪将其他人的平面数据加载到系统中的过程……这可能很有趣；但它基本上就像warehouse system 一样，您可以在其中跟踪发生的事情 - 文件写入磁盘、转换完成、导入完成 - 并创建报告。

同样进入方程，你是否要让模型对接下来发生的事情有权威？

这不是一个非常适合大量投资和定制代码的问题（说真的，您是否希望您的公司从 ETL 加载过程的出色表现中获得竞争优势？或者您只是构建它，因为您可以找不到合适的买？）

【讨论】：

【解决方案2】：

事件溯源是 CQRS 架构写入端的一种特殊类型的持久性，可以更好地捕获系统状态而不会造成任何损失。事件的历史记录用于写入端和读取端。

在您的情况下，如果您认为在每个命令之前从事件流中重建状态比使用平面/已计算状态更好，那么请使用事件源，否则不要。如果您仍然想要事件的历史记录，您可以使用仅用于重建旧的读取模型（以防它们不同步或识别出 BUG）或构建新的读取模型的事件日志。

【讨论】：

值得一提的是，ES 并不是专门为与 CQRS 一起工作而设计的，它们是正交方法。 ES 不需要 CQRS，CQRS 不需要 ES。
@MikeSW 如果没有any CQRS 架构，你将如何使用ES？（我不是说它不起作用，我只是好奇）
仅仅因为我们一起使用它们并不意味着它们是为其他设计的（在类似的注释中，DDD 和 OOP 一起使用，但足够多的开发人员正在使用函数式方法来实现 DDD）。并且有些应用程序（确实很少）不需要可查询模型。但是我经常使用没有 ES 的 CQRS。

【解决方案3】：

事件溯源用于存储（跟踪）域状态发生的变化。这些 xml 文件基本上是进口的。您可以将这些导入映射到导致可以存储的域事件的内部命令。如果您的应用是使用 ES 设计的，那么命令从哪里出现（大多数时候）都无关紧要。

如果您编写该导入组件并考虑专门为此使用 ES，这不是一个好主意。该活动本身就很笨拙，ES旨在处理复杂的领域（业务）模型。

【讨论】：