【发布时间】：2020-10-09 20:47:44
【问题描述】：
是否有人对带有 put/post 的 cqrs 有最佳实践模式，特别是客户端在发送命令/事件后正在获取更新的资源...您是否允许/要求客户端保留更新的本地副本资源，并在获取响应中发送最后更新的时间戳？或者确保 get 包含未处理的命令？当然，如果另一个客户端检索到相同的资源，则可能/不会获得更新的资源。 什么对你最有效？ 您是否会应对 get 也检查命令队列的额外复杂性？
【问题讨论】：
【发布时间】：2020-10-09 20:47:44
【问题描述】：
有没有人有关于 put/post 的 cqrs 的最佳实践模式，特别是客户端在发送命令/事件后正在获取更新的资源...
你会如何在网站上做到这一点？
通常，您会执行 GET 来加载资源，这将为您提供版本 0，可能在元数据中带有一些 validators，以让您知道您收到的表示版本。如果您再次尝试 GET 资源，通用组件可以从标题中看到您的副本是最新的，并会向您发回一条消息 (304 Not Modified)。
当您 POST 到该资源时，成功的响应会让所有中间组件知道该资源的先前缓存副本是 invalidated，因此下一个 GET 请求将检索包含所有修改的新副本.
这一切都很好，直到在 CQRS 设置中，读取请求遵循与写入请求不同的路径。读取端最终会自行更新，因此诀窍是如何避免将陈旧的表示返回给知道它应该已更改的客户端。
您正在寻找的类比是202 Accepted；我们希望写入端让客户端知道操作成功，并且有资源可以用来获取更改。
也就是说，写入端返回一个指示命令成功的响应，并提供一个链接，其中包含读取模型可以用来确定其副本是否是最新的数据的链接。
客户端的工作是跟踪链接，就像 REST 中的其他任何地方一样。
提供的链接当然会是一些安全操作，指向读取模型。读取模型将链接中的信息与当前可用表示的元数据进行比较；如果读取的模型副本是最新的，则返回该副本，否则返回一条消息，告诉客户端重试（大概在一段时间后）。
简而言之，我们在读取模型上使用轮询，等待它赶上来。
【讨论】：