【发布时间】：2019-08-12 07:26:14
【问题描述】：
将 CQRS 读取模型实现为聚合是否是个好主意？还是读取模型应该保留为 POCO 类？
【问题讨论】：
标签： domain-driven-design cqrs aggregateroot
【发布时间】：2019-08-12 07:26:14
【问题描述】：
将 CQRS 读取模型实现为聚合是个好主意吗？
不是吗？
AGGREGATE 是一组关联对象，我们将其视为一个单元，以便进行数据更改。
由于查询不会更改数据，因此聚合是不必要的仪式。将一堆业务数据放入一个对象中只是为了再次取出数据并没有多大意义。使用 POCO/POJO/plain 数据结构即可完成工作。
【讨论】：
-
查询不会改变对象，但读取模型事件处理程序会。
-
查询不改变数据并不是聚合不是 DTO 的原因。确实，聚合是通过根访问身份的相关数据集，被视为建立更改事务边界的单元；它们可以在内部查询或更改/删除；但这与它们没有映射到外部 API 合约的原因无关；聚合与搜索模型无关的原因是提供独立于内部细节的 API 契约，隐藏这些细节并保护 API 免受域模型演变的影响。
通常，在使用 CQRS 时，您还使用事件源设计，因此您没有 DDD 实体（以及通过扩展聚合 - 根本没有）。通常在使用 CQRS 时，您通常有一个“命令模型”和一个“查询/读取模型”，其中“命令模型”是一些事件队列，您可以每隔 X 时间“快照”一次；并且您的查询模型只是用例优化的搜索数据存储，您对建模整个聚合并不真正感兴趣。
现在，即使您没有使用事件源系统，并且您使用的 DDD 仅具有几个“查询/读取模型”，您也可能希望创建一个 DDD 模型并在“命令模型”上进行聚合而不是“读取模型”，因为您的“命令模型”代表您的域视图和对域的理解，反映了您的（DDD）无处不在的语言。读取/查询模型更倾向于针对特定用例微调性能（例如，在产品目录中快速搜索）；或用于使用其他“外部边界上下文”信息来丰富/聚合数据。
作为旁注，请务必注意，即使您的查询/读取模型不打算与您的聚合 1:1 匹配，但您的命令聚合和模型 DTO 之间通常存在一些相关性。
【讨论】：