【问题标题】:CQRS: How to implement a voting mechanism (many to many relationship)CQRS:如何实现投票机制(多对多关系)
【发布时间】:2017-07-24 08:52:16
【问题描述】:

我对 CQRS 和 DDD 比较陌生,我想知道在域模型中实现投票机制的最佳方式是什么。

在产品上,用户可以赞成/反对。有一些关于投票的域规则,f.e.您只能投票一次,无论是反对还是赞成。

投票和产品都是聚合根。这是最好的方法吗?建议保持聚合较小。将投票添加到产品聚合根会超时使其臃肿。

我正在努力解决的问题是当投票是聚合根时删除投票。您需要知道需要删除哪个投票聚合。命令处理程序无法使用 productId 和 userId 从存储库中检索投票。 aggregateId 作为单个 Guid 存储在数据库中。

该命令将包含这些字段

  • 用户ID
  • 产品编号

我发现的一些可能的解决方案:

  • 使用基于 userId 和 productId 的确定性 GUID
  • 投票是产品的汇总列表
  • 创建一个 voteId 并使用它来删除投票。
  • 将聚合存储为字符串并使用 productId 和 userId 的组合

最好的方法是什么?

【问题讨论】:

  • 标记为已删除是什么意思?您需要一个补偿操作,一个具有相同 UserId 和 ProductId 的新命令。
  • 会有一个具有相同 userId 和 productId 的新命令。然后,命令处理程序将获得投票并将其设置为已删除(已取消)。
  • 您能否也从业务角度而非纯技术角度进行解释?什么时候可以删除投票?这是用户取消投票的结果吗?是否还有更多需要这样做的情况?
  • 用户会看到两个按钮(upvote,downvote)。当用户按下 upvote 按钮时,他的投票就会被记录下来,并且该按钮会在 UI 上突出显示。当用户再次按下upvote按钮时,他的投票被取消。

标签: domain-driven-design cqrs event-sourcing


【解决方案1】:

根据我对您的领域的有限了解,我可以得出结论,有两个有界上下文 CatalogReviews。在这种情况下,您可以在 Catalog BC 中拥有一个 Product 聚合,在 Reviews BC 中拥有一个 Product 聚合。

来自Reviews BCProduct 聚合将包含特定产品的所有Vote 实体的列表。 Vote 实体将包含强制执行 vote only once 业务不变量所需的所有信息(如 IP 地址、用户 ID 等)。两种产品聚合类型(来自两个 BC)将共享相同的 ID - 如果您需要,这就是您保持它们同步的方式(例如,当产品从目录中删除时,它在评论 BC 中被标记为不可投票)。

【讨论】:

  • 听起来是一个很好的解决方案。在多个聚合类型上使用相同的 ID 是常见的做法吗?
  • @Valderann 非常常见且 DDD 基本。共享 ID 将来自多个有界上下文的聚合桥接起来,并允许将一个上帝般的聚合拆分为多个较小的聚合。
  • 感谢您的快速回复。这对我帮助很大。
猜你喜欢
  • 2018-07-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-06
  • 1970-01-01
  • 2012-06-05
相关资源
最近更新 更多