CQRS在NoSql中读取模型(Mongo DB) [英] CQRS Read models in a NoSql (Mongo DB)

查看:118
本文介绍了CQRS在NoSql中读取模型(Mongo DB)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的第一时间是DDD / CQRS。我已经阅读了多种知识,我仍然有点困惑,也许有人可以帮忙:)

Hi its my fist time with DDD/CQRS. I've read multiple sources of knowledge and Im still confused a bit, maybe someone could help :)

让我们假设一个简单的例子,即我们拥有产品和客户(可能有不同的界限)上下文)。
客户可以购买产品,并且他想查看他购买的所有产品。

Lets assume simple case that we have products and clients (possibly different bounded contexts). A client can buy a product and he wants to see all products that he purchased.

在这种情况下,我意识到我需要一个 UserPurchasesView 视图模型,其中:

In this case I realize I need a UserPurchasesView view model with:


  • purchaseId(这是mongo主键)

  • userId,

  • 产品:{id,名称,图像,shortDescription,[也许还有其他]]}

  • prize

  • timestamp

  • purchaseId (which is a mongo primary key)
  • userId,
  • product: {id, name, image, shortDescription, [maybe some others]}
  • prize
  • timestamp

现在...问题是我的域正在生成类似 UserPurchasedProduct(userId,productId)<的事件/ strong>。我可以通过奖品,产品名称或其他一些东西来丰富活动,但不是所有领域。我到达了一个似乎充实错误的地步。

Now ... the problem is that My domain is producing an event like UserPurchasedProduct(userId, productId). I could enrich an event with a prize, product name or maybe something else but not all fields. Im getting to a point where enriching seems to be wrong.

在这一点上,我意识到我需要类似 ProductDetailsView 的东西:

In this point I realize I need something like ProductDetailsView:


  • productId(主键)

  • prize

  • name

  • shortDescription

  • 徽标

  • productId (primary key)
  • prize
  • name
  • shortDescription
  • logo

此视图由以下事件维护:ProductCreated,ProductRename,ProductImageChanged

This view is maintained by events like: ProductCreated, ProductRenamed, ProductImageChanged

现在我们有2个选项...

And now we have 2 options ...


  1. 当出现UserPurchasedProduct事件时,请查看ProductDetailsView,获取所有必需的产品详细信息,并将其保存在UserPurchasesView中,以加快读取速度。该解决方案看上去还不错,但引入了一些额外的耦合,在我看来,这些视图在需要时无法很好地扩展。另外,从事件存储中答复所有事件时,必须将两个视图一起重建(在这种情况下,重建也比较棘手)。

  2. 在UserPurchasesView中仅保留productId,并在用户使用时读取多个视图查询他的购买。这是一些额外的处理,必须在某处完成。在前端,后端控制器或某些读取模型的高级API中。更新:我还意识到,我还需要至少将奖品和产品名称保留在UserPurchasesView中(以防更改),但有时您需要从购买之日起的价值,有时则需要最近的价值。方案取决于企业,但是我们可以想象两者。

这些解决方案对我来说都不是完美的。我错了吗,我错过了什么吗?还是只是这样做的方式?谢谢!

None of these solutions looks perfect to me. Am I wrong, am I missing something or is it just the way to do it? Thanks!

推荐答案

您了解得很好。

因此,您必须在读取模型之间的耦合与UI与单个读取模型之间的耦合之间进行选择。

So you have to choose between coupling between the read models and coupling between UI and individual read models.

CQRS / ES的主要优点之一是无需创建任何连接即可创建出色的快速读取模型(如果需要,可以创建视图),完美的缓存如我所见。我个人每次都选择第一种方法,即使用完全数据去规范化。视图非常快,模型非常干净清晰。 这是一个完美的解决方案,如果您想优化应用程序的读取端(我认为应该这样做)。
通过监听正确的事件,可以使这些读取的模型与应用程序的其余部分保持同步。

One of the main advantages of CQRS/ES is the posibility to create blazing fast read models (views if you like), without any joins, the perfect cache as I saw it called. I personally have chosen every time the first approach, with full data denormalisation. The views are very fast and models very clean and clear. This is the perfect solution if you want to optimize the read side of your application (and I think you should). By listening to the right events you can keep these read models in sync with the rest of the application.

这篇关于CQRS在NoSql中读取模型(Mongo DB)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆