想象一下像Twitter这样的服务，用户拥有一个锚名称和一个全名。遵循CQRS模式，您可以为包含推文正文和海报全名的推文生成视图。
您如何处理用户全名的更新？您是否想要启动一个漫长的过程来更新所有视图？我想的是用户有数以千计的推文。
答案 0 :(得分：0)
不要向精灵求助，因为他们会回答是和也许。
所以＆＃34;是＆＃34 ;;写模型中的数据已更改，因此从陈旧数据构建的一组视图已失效，应重建。因此，您可以考虑对具有关联的UsernameChanged事件的写入模型进行更改，并且该事件的订阅者知道该信号应该重建视图。
＆＃34;也许＆＃34 ;;无论如何，你可能已经有了这个漫长的过程。如果您正在以固定的时间表重建所有视图，则可能不需要跟踪哪些视图已失效。
＆＃34;也许＆＃34 ;; Udi Dahan写了关于这种事情，并做了以下观察
服务是特定业务能力的技术权威。
任何数据或规则必须仅由一项服务拥有。
他的想法是用户全名对于该服务是私有的 - 这将负责更新它和呈现它。该服务将实际数据保持为私有，仅发布标识符 - 一种代理键 - 以及一个小部件，它知道如何获取和呈现名称的表示。
因此视图不会被用户名数据的副本填充，而是用户名 widget 的副本，以及识别数据实例所需的状态。 ＃39;感兴趣的。因此，对用户名的更改不会改变＆＃34;视图＆＃34;一点都不。
答案 1 :(得分：0)
您将如何处理用户全名的更新？
这是历史推文所需要的东西吗？如果在发推文时他们有不同的名字，你可能会争辩说你根本不应该更新历史观点。然后时间线会在发推时显示他们的名字。这当然是一个商业决策。
如果需要，您的视图可以读取最新的NameChanged事件（例如），并将其用于每条推文，无论当时是什么。
最后我听说twitter如何存储其数据（我认为是播客），他们基本上每个用户都有一个查看所有推文的视图，所以如果我有100个粉丝，他们都会得到我的推文的副本在他们的时间表中....除非它是一个具有高跟随者数的用户，然后他们做了一些不同的事情（我可能完全错了！） - 在这种情况下，你的问题变得更糟，因为每条推文都会发送给每个人追随者的个人时间表。
我现在好奇实际发生了什么！ ：）
答案 2 :(得分：0)
我同意@tomliversidge提供的答案，但我的回复可能是评论的工具，所以请不要接受此作为“正确的”＃39;回答：）
将成为商业决策，了解历史数据会发生什么。
让我们再举一个例子来说明。当我下订单时，我订购的SKU-001恰好是一个红桶＆＃34;。然而，在等待我的订单完成某人的同时决定了＆＃34;红桶＆＃34;实际上是一个＆＃34;蓝桶＆＃34;。现在变得更有趣了。如果只有SKU-001的Id存储在订单上，则意味着我订购的产品现在已经改变了。这将导致相当多的混乱。虽然有各种方法。一种是存储历史数据并根据下订单的日期查找项目。但 非常复杂且效率低下。这就是为什么人们有时会存储一个包含Id和一些相关信息（如描述）的值对象。在订单示例中，肯定会不返回并更改历史数据的描述。
在这个特定的Twitter案例中，似乎更新了历史数据。现在，我不知道推特，我也不知道推特，所以我会稍微看一下。拥有用户全名也很有趣，因为问题变成了＃34;为什么名称改变了？＃34;？当一个女人结婚时，它经常发生。可能是业务决定保留旧的全名，因为它代表了那个时间点的事态。
但是，如果要更新数据，它也会成为一项技术练习。这里有选择。其中一个，如另一个答案所述，是在查找推文时简单地查找用户名。另一个，也说，是将数据非规范化为推文。某个地方的某个人知道这是如何运作的。即使我们必须对推文进行非规范化，也可能是针对读取模型的单个更新运行的问题。这完全取决于技术实施。
我的2美分：）