【问题标题】:How to handle MixedQuery with CQRS?如何使用 CQRS 处理 MixedQuery?
【发布时间】:2015-05-19 15:39:47
【问题描述】:

在正确设计的应用程序中,您可能可以将所有请求分离为命令(仅更新聚合并返回 void)和查询(从特定的读取优化模型中提取数据)。

但是,如果您已经有一个繁重的应用程序并希望将其缓慢移动到 ES + CQRS 路径,您可能会请求修改和更新模型并返回所有结果(如果您执行命令然后查询几乎相同,但这将是 2 个请求)这就是我所说的混合查询。

我知道这显然是个理论问题,我这里没有任何代码来演示它,但是

您如何使用 CQRS 处理此类请求?

【问题讨论】:

  • 与您之前所做的相比,这与 CQRS 的距离如何,甚至稍微接近一点?
  • 它不是,但我所做的是将它分成更小的项目、小的独立模块,现在我想用 CQRS 重构/重新设计它有很多事情要做。但是现在我在了解它是否可以处理我想要使用它的目的时遇到了一些问题......在实际迁移之前。

标签: architecture cqrs event-sourcing


【解决方案1】:

看来您基本上是在谈论牺牲 Command-Query Separation,这是 CQRS 的先决条件,也是一种一直以来的良好开发实践。

如果我要转向 CQRS 方法,我会开始遵守 CQS(如果有的话),在引入整个 CQRS 设备之前,仅在方法级别将查询与命令分开。

您不必像大爆炸一样进行返工,您可以逐个功能切片,确保您拥有高级自动化测试来确保重构安全。

【讨论】:

  • 好吧,忘掉大项目吧,假设我是从零开始写的,我想象的系统具有创建新用户的功能......你如何使用正确设计的 CQRS 应用程序来做到这一点?跨度>
  • 只是抽象地描述,例如客户端发送一个命令并在它之后立即查询?还是有别的东西?我无法继续前进,因为我看到的现实世界中的大多数用例确实是混合查询......
  • 如果我唯一的后端正在向用户发起任何更新,我可以完美地看到它的表现会有多好,但情况并非总是如此......
  • 您可能想要编辑您的问题或提出另一个问题,因为它似乎并不能反映您的实际需求(据我所知,在发送命令后刷新 UI)。
【解决方案2】:

您的“混合查询”超出了 CQRS 的范围。我的回答是——如果你有这个,你就没有 CQRS。 CQRS 意味着命令和查询是隔离的,这就是重点。

您不必立即将所有内容移至新模型,您将拥有两个并行系统,并逐个从一个移至另一个。我强烈不建议将旧的东西混入新模型中。

【讨论】:

  • 例如一个来自应用程序的简单请求,它想要创建一个新用户,它至少应该知道整个事情是否正常或失败......什么是正确的方法CQRS 的那种行为?我认为这是一个非常常见的例子......
  • 我可以想到的解决方案是,如果您与 websocket 之类的客户端进行全双工通信,那么在更新读取模型后,它可以向用户发送更新,但我认为大多数应用程序都不是这种情况......
  • 该命令可能会因异常而失败,这将很好地表明您的命令是否已完成。在 CQS 中,命令不返回任何内容,即状态突变方法总是无效的。当您的命令返回实际聚合时,可以构建流畅的界面,这也很好。但是 CQRS “将一个对象一分为二”,因此写入模型不应该从读取模型中查询任何内容,当然也不应该返回任何查询结果。
  • 如果没有 AJAX 或类似前端的 SPA,您如何处理这种“传统”情况:有一个控制器或请求处理程序(我们在 Web 上下文中)并且我们想要呈现一个带有列表,列表显然需要查询。现在我们做一个帖子,答案是如果表单数据无效应该包含列表数据来填充列表输入。所以我必须在同一个处理程序中执行查询和命令?
猜你喜欢
  • 2019-02-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-08-17
  • 2017-07-20
  • 1970-01-01
相关资源
最近更新 更多