80

我们以一个简单的“账户注册”为例，流程如下：

  • 用户访问网站
  • 点击“注册”按钮并填写表格，点击“保存”按钮
  • MVC 控制器：通过读取 ReadModel 来验证用户名的唯一性
  • RegisterCommand：再次验证用户名的唯一性（这里是问题）

当然，我们可以通过读取 MVC 控制器中的 ReadModel 来验证 UserName 的唯一性，以提高性能和用户体验。但是，我们仍然需要在 RegisterCommand 中再次验证唯一性，显然，我们不应该在 Commands 中访问 ReadModel。

如果我们不使用事件溯源，我们可以查询领域模型，所以这没有问题。但是如果我们使用事件溯源，我们无法查询域模型，那么我们如何在 RegisterCommand 中验证 UserName 的唯一性呢？

注意： User 类有一个 Id 属性，UserName 不是 User 类的关键属性。使用事件溯源时，我们只能通过 Id 获取域对象。

BTW：在需求中，如果输入的用户名已经被占用，网站应该向访问者显示错误消息“对不起，用户名XXX不可用”。不能向访问者显示“我们正在创建您的帐户，请稍候，我们稍后会通过电子邮件将注册结果发送给您”这样的消息是不可接受的。

有任何想法吗？非常感谢！

[更新]

一个更复杂的例子：

要求：

下单时，系统会检查客户的订单历史，如果他是有价值的客户（如果客户在去年每月至少下过10个订单，他是有价值的），我们对该订单进行10％的折扣。

执行：

我们创建 PlaceOrderCommand，在命令中，我们需要查询下订单历史，看看客户端是否有价值。但是我们怎么能做到呢？我们不应该在命令中访问 ReadModel！正如 Mikael所说，我们可以在帐户注册示例中使用补偿命令，但如果我们在此排序示例中也使用它，它会太复杂，代码可能太难以维护。

4

8 回答 8

39

如果您在发送命令之前使用读取模型验证用户名，我们正在谈论一个几百毫秒的竞争条件窗口，其中可能发生真正的竞争条件，在我的系统中没有处理。与处理它的成本相比，它不太可能发生。

但是，如果您觉得出于某种原因必须处理它，或者您只是想知道如何掌握这种情况，这里有一种方法：

使用事件溯源时，您不应从命令处理程序或域访问读取模型。但是，您可以做的是使用域服务来侦听 UserRegistered 事件，在该事件中您再次访问读取模型并检查用户名是否仍然不是重复的。当然，您需要在此处使用 UserGuid，并且您的读取模型可能已经使用您刚刚创建的用户进行了更新。如果发现重复，您有机会发送补偿命令，例如更改用户名并通知用户用户名已被使用。

这是解决问题的一种方法。

正如您可能看到的那样，不可能以同步的请求-响应方式执行此操作。为了解决这个问题，我们使用 SignalR 来更新 UI，只要有我们想要推送到客户端的东西（如果它们仍然连接的话）。我们所做的是让 Web 客户端订阅包含对客户端有用的信息的事件，以便立即查看。

更新

对于更复杂的情况：

我想说下订单不太复杂，因为您可以在发送命令之前使用读取模型来确定客户端是否有价值。实际上，您可以在加载订单时查询，因为您可能想向客户展示他们将在下订单之前获得 10% 的折扣。只需添加一个折扣PlaceOrderCommand，也许是折扣的原因，这样您就可以跟踪您削减利润的原因。

但是话又说回来，如果由于某种原因您确实需要在下订单后计算折扣，请再次使用会侦听的域服务，OrderPlacedEvent并且在这种情况下，“补偿”命令可能是 aDiscountOrderCommand或其他东西。该命令将影响 Order Aggregate 根，并且信息可以传播到您的读取模型。

对于重复用户名的情况：

您可以从域服务发送 aChangeUsernameCommand作为补偿命令。甚至更具体的内容，这将描述用户名更改的原因，这也可能导致创建 Web 客户端可以订阅的事件，以便您可以让用户看到用户名是重复的。

在域服务上下文中，我会说您还可以使用其他方式通知用户，例如发送电子邮件，这可能很有用，因为您无法知道用户是否仍处于连接状态。也许通知功能可以由 Web 客户端订阅的同一事件启动。

谈到 SignalR，我使用了一个 SignalR Hub，用户在加载特定表单时连接到该中心。我使用 SignalR Group 功能，它允许我创建一个组，我将其命名为我在命令中发送的 Guid 的值。在您的情况下，这可能是 userGuid。然后我有 Eventhandler 订阅可能对客户端有用的事件，当事件到达时，我可以在 SignalR 组中的所有客户端上调用 javascript 函数（在这种情况下，只有一个客户端在您的案子）。我知道这听起来很复杂，但事实并非如此。我一个下午就搞定了。SignalR Github 页面上有很棒的文档和示例。

于 2012-02-29T09:03:55.587 回答
26

我认为您尚未将思维方式转变为最终的一致性和事件溯源的性质。我有同样的问题。具体来说，我拒绝接受您应该信任来自客户端的命令，使用您的示例说“以 10% 的折扣下订单”，而域没有验证折扣应该继续。对我来说真正打动人心的一件事是Udi 自己对我说的话（查看已接受答案的评论）。

基本上我开始意识到没有理由不信任客户。读取端的所有内容都是从域模型生成的，因此没有理由不接受命令。阅读方面表明客户有资格获得折扣的任何内容都已被域放在那里。

BTW：在需求中，如果输入的用户名已经被占用，网站应该向访问者显示错误消息“对不起，用户名XXX不可用”。不能向访问者显示“我们正在创建您的帐户，请稍候，我们稍后会通过电子邮件将注册结果发送给您”这样的消息是不可接受的。

如果您打算采用事件溯源和最终一致性，您将需要接受有时在提交命令后无法立即显示错误消息的事实。使用唯一的用户名示例，发生这种情况的可能性非常小（假设您在发送命令之前检查了读取端）它不值得担心太多，但需要针对这种情况发送后续通知，或者可能会询问他们下次登录时使用不同的用户名。这些场景的伟大之处在于它让你思考商业价值和真正重要的事情。

更新：2015 年 10 月

只是想补充一点，实际上，在涉及面向公众的网站的情况下 - 表明电子邮件已经被接收实际上是违反安全最佳实践的。相反，注册似乎已成功通知用户已发送验证电子邮件，但在用户名存在的情况下，电子邮件应通知他们并提示他们登录或重置密码。虽然这仅在使用电子邮件地址作为用户名时才有效，但我认为出于这个原因这是可取的。

于 2012-02-29T19:55:36.430 回答
23

创建一些在与命令相同的事务中更新的立即一致的读取模型（例如，不通过分布式网络）并没有错。

使读取模型在分布式网络上最终保持一致有助于支持对重度读取系统的读取模型进行扩展。但是没有什么可以说你不能拥有一个立即一致的特定领域的读取模型。

立即一致的读取模型仅用于在发出命令之前检查数据，您不应该将其用于直接向用户显示读取数据（即来自 GET Web 请求或类似请求）。为此使用最终一致、可扩展的读取模型。

于 2015-05-12T05:57:34.950 回答
10

关于唯一性，我实现了以下内容：

  • 第一个命令，例如“StartUserRegistration”。无论用户是否唯一，都会创建 UserAggregate，但状态为 RegistrationRequested。

  • 在“UserRegistrationStarted”上，异步消息将被发送到无状态服务“UsernamesRegistry”。类似于“RegisterName”。

  • 服务会尝试更新（没有查询，“告诉不要问”）包含唯一约束的表。

  • 如果成功，服务将回复另一条消息（异步），并带有一种授权“UsernameRegistration”，说明用户名已成功注册。您可以包含一些 requestId 以在并发能力的情况下进行跟踪（不太可能）。

  • 上述消息的发布者现在已经授权该名称是自己注册的，因此现在可以安全地将 UserRegistration 聚合标记为成功。否则，标记为丢弃。

包起来：

  • 这种方法不涉及查询。

  • 用户注册将始终在没有验证的情况下创建。

  • 确认过程将涉及两条异步消息和一个数据库插入。该表不是读取模型的一部分，而是服务的一部分。

  • 最后，一个异步命令来确认用户是有效的。

  • 此时，反规范化器可以对 UserRegistrationConfirmed 事件做出反应并为用户创建读取模型。

于 2018-08-30T00:48:09.313 回答
8

像许多其他人一样，在实现基于事件源的系统时，我们遇到了唯一性问题。

起初，我支持让客户端在发送命令之前访问查询端，以查明用户名是否唯一。但后来我发现拥有一个对唯一性进行零验证的后端是个坏主意。当可以发布会破坏系统的命令时，为什么还要强制执行任何操作？后端应该验证它的所有输入，否则您将打开不一致的数据。

我们所做的是index在命令端创建一个表。例如，在用户名需要唯一的简单情况下，只需创建一个 user_name_index 表，其中包含需要唯一的字段。现在命令端能够查询用户名的唯一性。执行命令后，将新用户名存储在索引中是安全的。

类似的东西也可以解决订单折扣问题。

好处是您的命令后端会正确验证所有输入，因此不会存储不一致的数据。

缺点可能是您需要对每个唯一性约束进行额外查询，并且您正在执行额外的复杂性。

于 2015-12-24T08:30:08.520 回答
7

我认为对于这种情况，我们可以使用“有到期的咨询锁”之类的机制。

示例执行：

  • 检查用户名是否存在于最终一致的读取模型中
  • 如果不存在；通过使用像键值存储或缓存这样的 redis-couchbase；尝试将用户名推送为具有一定期限的关键字段。
  • 如果成功；然后引发 userRegisteredEvent。
  • 如果读取模型或缓存存储中存在任何用户名，则通知访问者用户名已被占用。

甚至可以使用 sql 数据库；插入用户名作为某个锁表的主键；然后计划的作业可以处理到期。

于 2015-07-14T09:14:04.093 回答
2

您是否考虑过使用“工作”缓存作为一种 RSVP？很难解释，因为它在一个周期内工作，但基本上，当一个新的用户名被“认领”（即，发出创建它的命令）时，你将用户名放入缓存中，并有一个短暂的过期时间（足够长的时间来解释另一个请求通过队列并非规范化到读取模型中）。如果它是一个服务实例，那么在内存中可能会起作用，否则用 Redis 或其他东西集中它。

然后，当下一个用户填写表单时（假设有一个前端），您异步检查读取模型以了解用户名的可用性，并在用户名已被占用时提醒用户。提交命令时，检查缓存（不是读取模型），以便在接受命令之前验证请求（返回 202 之前）；如果名称在缓存中，则不接受该命令，如果不是，则将其添加到缓存中；如果添加它失败（重复键，因为其他一些过程打败了你），然后假设名称被采用 - 然后适当地响应客户端。这两件事之间，我认为不会有太多发生碰撞的机会。

如果没有前端，那么您可以跳过异步查找，或者至少让您的 API 提供端点来查找它。无论如何，您确实不应该允许客户端直接与命令模型对话，并且在其前面放置一个 API 将允许您让 API 充当命令和读取主机之间的中介。

于 2017-07-30T19:32:18.057 回答
2

在我看来，这里的汇总可能是错误的。

一般而言，如果您需要保证属于 Y 的值 Z 在集合 X 中是唯一的，则使用 X 作为聚合。毕竟，X 是不变量真正存在的地方（X 中只能有一个 Z）。

换句话说，您的不变量是用户名只能在您的所有应用程序用户的范围内出现一次（或者可能是不同的范围，例如在组织内等）如果您有一个聚合的“ApplicationUsers”并发送“RegisterUser”命令，那么您应该能够拥有所需的内容，以确保该命令在存储“UserRegistered”事件之前有效。（当然，您可以使用该事件来创建您需要的投影，以便执行诸如验证用户之类的操作，而无需加载整个“ApplicationUsers”聚合。

于 2019-04-10T21:48:17.523 回答