用于数据治理的多个分布式事件存储协同工作答案

【问题标题】：Multiple distributed event stores for data governance working together用于数据治理的多个分布式事件存储协同工作
【发布时间】：2017-05-22 05:22:25
【问题描述】：

我玩了几个月的 CQRS/事件溯源。目前，我在尝试进行另一项实验时遇到问题，希望有人可以提供帮助、解释甚至暗示事件溯源以外的另一种方法。

我想构建一个分布式应用程序，其中每个用户都可以管理他/她的数据。所以我的想法是每个用户都拥有自己的事件存储，而其他用户可以（有条件地）访问它。

当用户 A 执行某个命令时，这可能意味着不止一个事件存储。两个例子：

1) 从由事件存储 A 和 B 托管的任务列表中删除共享任务

2) 将对事件存储 A 中持久化的评论的引用添加到事件存储 B 中持久化的帖子中。

我目前唯一的解决方案似乎是使用附加到每个事件存储的流程管理器，因此当一个事件被添加到一个事件存储时，saga 也处理将该事件应用于其他相关事件存储。

【问题讨论】：

不清楚为什么每个用户都必须拥有自己的事件存储。你能详细说明一下吗？
@IlliakaillI：我有一个系统正在运行，每个用户都有几个包含敏感数据的列表。有些列表应该与其他用户共享，有些则不应该。目前，这是我的私人资料，所以只有少数用户。但我计划发布它，许多用户将不相信将这些敏感数据信任给未知服务。这就是为什么我要让用户管理他们的数据以及共享部分数据的可能性。

【解决方案1】：

不确定您的解决方案的目的是什么，但如果您希望一个系统对来自另一个系统的事件做出反应，在将事件保存到商店后，订阅（如 Greg Young 的 EventStore 提供的追赶订阅）会发布它在使用 pub-sub 的消息总线上，所有相关方都可以处理此事件。

但是，如果他们只是将此事件“保存”到他们的商店，那就错了。事实上，他们应该有一个事件处理程序，它将在本地服务中产生一个命令，如果满足所有条件，这个命令可能（或可能不会）导致一个本地事件。只有发生在边界内、在本地控制下的事情，才应该保存到本地存储中。

【讨论】：

谢谢，我想到了与 Greg Young 的事件存储中的此订阅类似的架构。但是... 1) 我的事件不得提交给不允许的系统，即只能提交给允许查看数据的系统。是否存在条件访问消息总线之类的东西？ 2) 假设系统 A 处理命令并向系统 B 发出事件。 B 将从它产生一个命令并尝试处理它。如果它成功了，很好，但如果没有，向系统 A 发出另一个事件以表示失败是否有意义，或者我将如何处理它？