有没有人使用 ElasticSearch 在 CQRS 方法中构建读取模型?我有一些与此类解决方案相关的问题:
- 您将域事件存储在哪里?在 JDBC 数据库中?在弹性搜索中?
- 您是通过处理域事件的事件处理程序还是使用 ElasticSearch River 功能来构建索引?
- 您如何处理视图模型的完全重建 - 例如,当视图损坏时?您是否处理所有事件以重建视图?
有没有人使用 ElasticSearch 在 CQRS 方法中构建读取模型?我有一些与此类解决方案相关的问题:
域事件的权威存储库所在的位置是实现细节。例如,您可以在 S3 或 CouchDB 或任何其他数量的存储实现上存储序列化版本。如果您刚刚开始,最简单的方法是关系数据库。
通常,人们使用事件处理程序来了解每条消息背后的业务意图,然后可以将消息正确地反规范化为适合您的视图需求的读取模型结构。
如果视图模型曾经损坏或者您在视图模型处理程序中存在错误,则在修复错误后有几个简单的步骤可以执行:
将来自域的事件流临时排入队列——这些是在您的域工作时发布的典型消息。我们仍然想要这些信息,但还不是现在。这可以通过关闭任何消息总线或不连接到您的队列基础设施(如果您使用一个)来完成。
从事件存储中读取所有事件。接收到每个事件后(这可以通过简单的 DB 查询来完成),通过适当的消息处理程序运行每个消息。确保跟踪所有已处理消息的最后 10,000 个(左右)标识符。
现在重新连接到您的队列并开始正常处理。如果已看到消息的标识符,则丢弃该消息。否则,正常处理。
跟踪标识符的原因是为了避免竞争条件,即您从事件存储中获取所有事件,但同一消息正在通过消息队列。
另一种高度相关但涉及跟踪所有消息标识符的技术可以在这里找到:http: //blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.html