domain-driven-design - 在命令处理程序/域服务中使用查询模型

标签 domain-driven-design cqrs

我是否应该使用 Query 模型来组合/检查某些聚合信息,例如在域服务中?我已经在很多例子中看到了这一点。但是如果查询数据是异步传播的,作为域事件的结果呢?

示例:具有用户聚合和消息聚合的留言板(为较小的 trx 边界解耦)。
当一个用户被标记删除时,他的所有消息也需要被标记删除。这将通过在 MessageEventHandler 类型的服务中处理 UserMarkedDeletedEvent 来完成。现在,此服务需要为具有特定用户的每条消息触发 DeleteMessageCommands。为了找到消息,需要进行查询。我想这必须在读取模型上完成,由于异步更新可能会过时......(我猜唯一的选择是事件溯源的读取/查询模型)

最佳答案

为了性能,这样做是可以的。但是您应该知道您真正询问读取模型的内容以及它的含义。

根据您的域,可能存在永远不会改变或一旦到达就返回的状态。如果您向读取模型询问这些状态之一,那么您可以声明这是事实。

但是这样你只能声明命令无效或 也许有效的。真正的真理存在于总体中。

例子:

foo 聚合可以 - 一旦删除 - 永远不会被取消删除(域规则)并且此状态处于读取模型中。如果您从读取模型中获得此已删除状态,那么您可以说该命令 - 仅对未删除的 foos 有效 - 无效。但是你不能说它是一个有效的命令,因为聚合可能已经被删除并且没有写入读取模型。

关于domain-driven-design - 在命令处理程序/域服务中使用查询模型,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32410578/

相关文章:

concurrency - CQRS 读取端、多个事件流主题、并发/竞争条件

domain-driven-design - ddd中上游上下文和下游上下文之间的关系

domain-driven-design - 分布式域驱动设计资源

C# DDD - 域对象创建

azure - NCQRS 和 Lokad.CQRS 之间的差异

oop - CQRS:在 ICommandExecutor.Execute() 方法中返回结果好吗?

domain-driven-design - 值对象与实体

php - ddd - 与远程 API 的同步应该去哪里?

entity-framework - 使用 DDD 和 IoC 为 EF4 实现存储库

architecture - CQRS 可以用于像 StackOverflow 这样的网站吗?