DDD：谁能解释 DTO、Aggregate Root 和 Detached Entity 之间的区别？

Question

我有点搞不懂这三者之间的区别。假设我有一个客户 - > 地址关系，（JPA）分离实体也将有这个（假设是急切加载）。哪里需要额外的聚合根？哪里需要 DTO？都差不多吗？

其中一个原因可能是符合 JPA 的实体有一些客户根本不感兴趣的信息，例如@Entity, @Id, @OneToMany.

我可以使用 JAX-RS/-WS 轻松地将其转换为 JSON/XML，并且几乎每个客户端都可以处理它，那么哪里需要它呢？是几乎一样还是我错过了一些重要的事情？

Answer 1

嗯，我真的不明白你真正的需要是什么？您尝试使用 DDD 概念或 DTO 解决的问题是什么...

DTO 无法与聚合根（实体也是如此）相提并论，实体具有数据和行为（DTO 不是这种情况，它只是数据）。

因此，域模型应该是域驱动的 ;-)，并且一些构建块对于实现它很有用，例如：实体、聚合...当您使用 ORM 时，可能很难隔离您的域，因此您必须尝试在您的域中拥有一些纯净的东西，并且尽可能减少噪音。有很多策略可以解决它。

您可以在那里找到更多信息：http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/

Answer 2

如果您遵循 DDD 原则，无论您是否使用 JPA，您都将创建 聚合根。这是 DDD 中非常基本的构建块之一。来自 Eric Evan 的 DDD 书：

聚合标记了不变量必须存在的范围 在生命周期的每个阶段进行维护。以下模式， 工厂和存储库，在聚合上运行。

DTO 和分离实体与 JPA（技术约束）相关。 聚合根也是一个实体。当聚合根变为非托管（通过持久化上下文）时，它被称为分离实体。

也许您的问题可以改写为：我应该将聚合根返回为分离实体还是DTO？答案是主观的，取决于您的环境。

将聚合根作为分离实体返回的好处是您不需要创建新的DTO类。您还可以调用 聚合根 拥有的方法。缺点是您通常不会出于性能原因填充完整的对象图，因为某些 聚合根 可能具有非常深的层次结构。如果处理不当会导致延迟加载异常。

返回 DTO 而不是 聚合根 被认为是更健壮的设计。您将需要为 聚合根 的每个“用例” 创建一个新的 DTO 类。这对于小型系统来说可能太麻烦了，但是如果您使用的是 DDD，我相信您的要求很复杂。