我正试图弄清楚我的事件存储和我的阅读模型在实际的螺母和螺栓实现方面是如何相关的。
我对活动商店的了解有限让我相信：
这意味着如果公共交通发生任何事情，我的阅读数据库将不同步，我必须弄清楚如何同步它。
我已阅读/观看过的一些内容由greg young发布，建议将事件存储本身用作队列，并通过在事件存储端保留自动增量编号来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实现了？
答案 0 :(得分：1)
所以我的读取数据库获取消息（mysql）
我会重新说明“我的事件处理器对于给定事件获取消息并且（在我的情况下）通常会操纵mysql数据库中的状态”（或者你的意思是其他什么？）。
这意味着如果公共交通发生任何事情，我的阅读数据库将不同步，我必须弄清楚如何同步它。
是的，您的队列成为应用状态的一部分，需要备份并具有弹性。请注意，Dispatcher在成功将其放入队列之前不会标记Commit，并且在您确认完成处理以执行必要的更新以同步您的状态之前，排队系统不会删除该消息阅读模型。
请记住，您可以将多个Web服务调用视为处理事件所必需的工作的一部分。
要记住的另一件事是，您希望您的事件处理器具有幂等性（即能够在至少一次交付时处理）。
如果活动无法完成处理，那么考虑到你要做什么，你会很开心 - 你会去死信吗？谁会对此进行监控？
BTW取决于您的托管安排，Azure（或内部部署的Windows）ServiceBus可能值得考虑）
我已阅读/观看过的一些内容由greg young发布，建议将事件存储本身用作队列，并通过在事件存储端保留自动增量编号来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实现了？
不，JOES为您提供Dispatcher挂钩，然后您决定什么是适合您的。这是好事还是坏事。有些系统根本没有将Dispatcher绑定到有状态读取模型 - 它们只是在事件存储中查询事件并构建一个内存读取模型来短路所有这些。
不确定自动递增数字是什么意思。
请注意GES中的投影内容还不完全是1.0（但不言而喻，它非常值得您的强烈考虑 - 它本质上处理了您对这些问题所涉及的大部分问题）