CQRS：模型属性的更新是否意味着缓存该属性的所有视图的更新？答案

【问题标题】：CQRS: Does the update of a model property imply the update of all the views caching that property?CQRS：模型属性的更新是否意味着缓存该属性的所有视图的更新？
【发布时间】：2016-07-12 16:08:00
【问题描述】：

想象一下像 Twitter 这样的服务，其中用户有一个锚点名称和一个全名。按照 CQRS 模式，您可以为包含推文正文和海报全名的推文生成视图。

您将如何处理用户全名的更新？您是否想启动一个漫长的过程来更新所有视图？我正在考虑用户拥有数千条推文的场景。

【问题讨论】：

嗯，这就是 Twitter 所做的 - Timelines at Scale / The Architecture Twitter Uses To Deal With 150M Active Users, 300K QPS, A 22 MB/S Firehose, And Send Tweets In Under 5 Seconds。我记得，它们的读取与写入是分开的，这与 CQRS 非常相似。
尤里卡。基本上他们正在做我在发现 DDD 和 CQRS 之前所做的事情（我讨厌加入）：由于时间线只包含推文 ID，他们必须“水合”这些推文，即找到推文的文本。给定一组 ID，他们可以执行 multiget 并从 T-bird 并行获取推文。 我敢打赌，他们对 UserId 也是如此。

标签： domain-driven-design cqrs

【解决方案1】：

不要向精灵寻求建议，因为他们会回答“是”和“也许”。

所以“是”；写入模型中的数据已更改，因此从陈旧数据构建的一堆视图已失效，应该重新构建。因此，您可以认为写入模型的更改具有关联的 UsernameChanged 事件，并且该事件的订阅者知道发出应该重建视图的信号。

“也许”；无论如何，您可能已经有那个长时间运行的过程。如果您按照固定的时间表全部重建它们，您可能不需要跟踪哪些视图已失效。

“也许”； Udi Dahan写了这样的事情，并做了以下观察

服务是特定业务能力的技术权威。

任何一条数据或规则都必须由一个服务拥有。

他的想法是，用户全名对该服务是私有的——该服务将负责更新它并呈现它。该服务会将实际数据保密，只发布一个标识符（一种代理键）和一个小部件，它知道如何获取和呈现名称的表示。

因此视图不会填充用户名数据的副本，而是用户名widget的副本，以及识别感兴趣的数据实例所需的状态.因此，更改用户名根本不会改变“视图”。

【讨论】：

感谢您的回答。如果您使用 FullName 小部件，您不会在每个“推文”中查询一次 DB/Cache 吗？看起来效率不是很高，是吗？
不，小部件将在每条推文中查询一次其本地数据存储。
是的，您向用户展示的每条推文/视图都会点击一次。
本地数据存储——效率不错。
你知道关于这个特定主题的任何文章或书籍吗？除了一次更新的简单案例之外，我找不到任何东西。

【解决方案2】：

您将如何处理用户全名的更新？

历史推文需要它吗？你可能会争辩说，如果在发布推文时它们有不同的名称，你根本不应该更新历史视图。然后，时间线会在发推文时显示他们的名字。这当然是一个商业决策。

如果需要，您的视图可以读取最近的 NameChanged 事件（例如），并将其用于每条推文，无论当时是什么。

我最后一次听说 twitter 如何存储其数据（我认为来自播客）是他们基本上每个用户都有一个视图，其中所有推文都被复制，所以如果我有 100 个关注者，他们都会得到我推文的副本在他们的时间线中......除非它是一个拥有大量关注者的用户，否则他们会做一些不同的事情（我可能完全错了！） - 在这种情况下，你的问题会变得更糟，因为每条推文都会进入每个关注者的个人时间线.

我现在很好奇到底发生了什么！ :)

【讨论】：

刚刚测试了在 twitter 上更改我的个人资料名称，它确实在另一个用户的时间线中更新，即使对于历史推文也是如此
正是 tomliversidge，这就是我问的原因。

【解决方案3】：

我同意@tomliversidge 提供的答案，但我的回复可能会成为评论工具，因此请不要将其视为“正确”答案:)

将是一个关于历史数据会发生什么的商业决策。

我们再举一个例子来说明。当我下订单时，我订购了 SKU-001，它恰好是一个“红桶”。然而，在等待我的订单完成时，有人认为“红桶”实际上是“蓝桶”。现在它变得更有趣了。如果订单上只存储了 SKU-001 的 ID，则意味着我所订购的商品现在已更改。这将导致相当多的混乱。不过有办法解决这个问题。一种是存储历史数据并根据下订单的日期查找项目。但是那个是非常复杂和低效的。这就是为什么有时会存储一个包含 Id 和一些相关信息（例如描述）的值对象。在订单示例中，当然不会返回并更改历史数据的描述。

在这个特定的 Twitter 案例中，历史数据似乎已更新。现在，我不知道 twitter，我不在上面，所以我会以不同的方式看待它。拥有用户全名也很有趣，因为问题变成了“为什么更改名称”？当一个女人结婚时，这种情况经常发生。可能是企业决定保留旧的全名，以代表当时的情况。

但是，如果要更新数据，它也会成为一项技术练习。这里有选项。如另一个答案所述，一个是在查找推文时简单地查找用户名。另一种说法是，将数据非规范化到推文中。某个地方的某个人知道这是如何工作的。即使我们必须对推文进行非规范化处理，也可能只是针对读取模型运行一次更新。这一切都将取决于技术实现。

只要我的 2 美分 :)

【讨论】：