理解 Lagoms 持久读端

Question

我通读了 Lagom 文档，并且已经编写了一些相互交互的小服务。但是因为这是我第一次涉足 CQRS，所以我仍然有一些关于持久读取方面的概念性问题，我不太了解。

例如，我有一个用户服务，它保存了一个用户列表（作为聚合）及其个人资料数据，如电子邮件地址、姓名、地址等。

我现在的问题是

• 如果我想检索给定电子邮件地址的用户配置文件，我是否应该在读取端查询用户 ID，然后使用此 ID 查询事件存储以获取配置文件数据？还是应该读取端已经保留所有配置文件信息？

• 如果读取端有所有信息，事件存储的原因是什么？如果它真的是只写的，它不是真的有用吗？

• 我应该设计我的系统以尽可能多地使用事件存储，还是应该为所有内容提供读取端？可扩展性有何影响？

• 如果用户模型更改（例如，配置文件现在包含配置文件的描述）并且我使用包含所有配置文件数据的读取端，我如何将 lagom 中的读取端更新到现在也包含此说明？

• 根据这个问题，我应该为配置文件的不同字段保留不同的读取边表，而不是一个包含整个配置文件的表

• 如果不同的服务需要访问数据，它应该总是询问用户服务，还是应该根据需要保留自己的读取端？如果是后者，这是否违反了 CQRS 原则，即拥有数据的服务应该是唯一读取和写入该数据的服务？

如您所见，整个概念还没有真正“点击”，我很感谢您的回答和/或一些指示。

Answer 1

如果我想检索给定电子邮件地址的用户配置文件，我是否应该在读取端查询用户 ID，然后使用此 ID 查询事件存储以获取配置文件数据？还是应该读取端已经保留所有配置文件信息？

您应该使用专门设计的 ReadModel 来使用电子邮件地址搜索个人资料。您应该只查询事件存储以重新水化聚合，并且您重新水化聚合只是为了向它们发送命令，而不是查询。在 CQRS 中不能查询聚合。

如果读取端有所有信息，事件存储的原因是什么？如果它真的是只写的，它不是真的有用吗？

事件存储是写入端（聚合）的真实来源。它用于在进程命令之前重新水化聚合（它们根据先前发出的事件重建其内部和私有状态）并持久化新事件。所以事件存储是只追加的，但也用于读取事件流（聚合实例发出的事件）。 Event-store 确保 Aggregate 实例（即由类型和 ID 标识）一次只处理一个命令。

如果用户模型更改（例如，配置文件现在包含配置文件的描述）并且我使用包含所有配置文件数据的读取端，我如何在 lagom 中更新此读取端以现在也包含此说明？

除了我自己的，我没有使用任何其他框架，但我猜你重写（使用事件上新添加的字段）并重建 ReadModel。

根据这个问题，我是否应该为配置文件的不同字段保留不同的读取侧表，而不是一个包含整个配置文件的表

每个用例都应该有一个单独的 ReadModel（带有自己的表）。 ReadModel 应该非常快，这意味着它应该尽可能小，只有特定用例所需的字段。这非常重要，它是使用 CQRS 的主要好处之一。

如果不同的服务需要访问数据，它应该总是询问用户服务，还是应该根据需要保留自己的读取端？如果是后者，这是否违反了 CQRS 原则，即拥有数据的服务应该是唯一读取和写入该数据的服务？

这取决于你，建筑师。最好是每个 ReadModel 都拥有自己的数据，也就是说，它应该订阅正确的事件，它不应该依赖于其他 ReadModel。但这会导致大量代码重复。根据我的经验，我希望拥有一些拥有一些数据但也可以按需共享数据的规范 ReadModel。为此，在 CQRS 中，还有术语query。就像命令和事件一样，查询可以在您的系统中传播，但只能从 ReadModel 到 ReadModel。

不应在客户请求期间发送查询。它们应该仅在后台发送，作为异步同步机制。这是影响系统弹性和响应能力的一个重要方面。

我还使用实时查询，当答案发生变化时，这些查询会从权威的 ReadModel 实时推送到订阅的 ReadModel。

如果是后者，这是否违反了 CQRS 原则，即拥有数据的服务应该是唯一读取和写入该数据的服务？

不，它没有。 CQRS 没有指定如何更新R（读取端），只是说明R 不应该处理命令并且C 不应该被查询。