Event sourcing 如何在事件源系统中处理合法强制执行的数据删除请求？

在事件源系统中，事件形式的历史数据永远不会被丢弃。这样做可能会导致状态损坏。现在想象一下，有一个法庭裁决，指出一些数据需要删除（例如，搜索引擎必须删除隐私特定的数据）。你将如何做到这一点

这是一个问题

到目前为止，我已经知道了两种可能性

简单的第一部分：如果您使用事件源，那么您的所有数据视图都应该可以从事件存储中的事件派生出来。因此，在从事件存储区中清除受污染的数据后，您为读取而存储的所有数据（缓存、屏幕、投影、报告）都可以被清除并重新生成

所以你只需要找出那一部分

首先，如果受污染的数据从未进入存储区，您不必担心将其清除。例如，可以在键值存储中隔离敏感信息；事件存储中对该数据的引用总是通过代理键进行的。当您需要清理时，键值存储中的数据将被删除，您有一系列事件指向不再可读的内容，您只需要确保在引用数据不可用时，您的读取模型可以继续工作

如果数据确实需要进入事件存储——因为需要它来维护域模型的完整性——那么“聚合”的想法可能会有所帮助

聚合是一个来自的想法，基本想法是您的域可以分解为不需要直接共享数据的元素。在聚合上，从不直接引用另一个聚合中的数据；相反，您使用ID的间接引用；ID本身是另一个代理密钥

由于这些聚合相互隔离，因此它们可以有自己的事件历史。在这种情况下，只需删除任何已被污染的聚合，即可清除受污染的数据。您只需删除事件流

这样的响应不会使您处于损坏状态，只是不一致。一切仍在运行，只是缺少一堆数据

工具箱中还有“补偿事件”的武器；您可能能够引入一个新的事件流，使系统恢复到一致状态。例如，如果清理一系列交易使账簿失去平衡，那么您可能会发布一个事件，对我造成指控，然后