design-patterns - CQRS 中的实体与 DTO

标签 design-patterns entity domain-driven-design dto cqrs

在一个普通的 DDD 项目中,我希望从存储库中检索到的实体作为 DTO 从域层发送到应用层。

CQRS 存在的原因之一似乎是应用层所需的查询(主要是读取操作)与域层所需的查询不同。所以看起来即使是同一个对象的查询结果在不同层之间也可能不同。

在我的域层中,我已经将查询结果映射到域实体中。我对一些 CQRS 示例将查询结果直接映射到 DTO 跳过它们的匹配实体感到困惑。

假设一个数据库返回:

{"person": {
  "id:": 5323423,
  "name": "John",
  "family_name": "Smith"
  ...
}}

但是实体布局将姓氏映射为姓氏:
class Person
{
   Identity id;
   String name;
   String surname;
}

如果在我看到的某些 CQRS 示例中发生这种情况,则提取的 DTO 看起来会有所不同,从而在将实体与其 DTO 进行匹配时会导致冲突。这些冲突如何解决?在我看来,任何 DTO(与实体相关)都应始终从其实体生成。然而,在这种情况下,在应用层中执行不同类型查询的自由会丢失。

最佳答案

关键是你没有将实体映射到 DTO。 DTO 由特定上下文需要什么定义,并成为查询/读取模型。当实体更新时,事件处理程序也将使用它来更新读取模型。

所以基本上读取模型是从所有需要的实体(1 个或更多)生成和更新的,通常以增量方式。

关于design-patterns - CQRS 中的实体与 DTO,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19620404/

相关文章:

c++ - 模拟器的状态机

scala - Scalding TypedPipe API 外部操作模式

java - 在表中快速查找行的算法

entity-framework - 更新 Entity Framework 对象

java - 检查用户是否被另一个用户阻止的最佳位置

javascript - 在游戏开发中处理战斗效果

java - Spring根据表中的行数生成ID

sql - JPA - 更新嵌入实体会生成无效的 SQL

design-patterns - 您使用工厂而不是构造函数来创建对象的阈值是多少?

domain-driven-design - DDD - 应该实现哪一层 DTO