从 DDD 实体/聚合中提取数据

Question

有人可以澄清以下主题吗？我还没有找到足够复杂的答案，只是一些基本的例子来说明它应该如何工作，所以我在这里问。

假设我们有一个实体发票。 Invoice 有一些私有属性，例如开具日期、付款日期、物品等。

根据 DDD 的原则，域应该只关心自己，而不关心周围的世界。如果是发票，则意味着您可以开具，可以添加项目，您可能可以更改付款日期等。

但是发票有责任关心从中提取数据吗？我的意思是，例如在 Doctrine 中，您将为所有属性创建吸气剂，这绝对没问题。但我相信这不是你想在 DDD 中做的事情——我认为 Invoice 应该只关心它的状态和修改它，而不是为它的所有属性提供数百个 getter。

所以我的问题是 - 将数据从实体提取到例如的最佳方法是什么？ DTO？真的是吸气剂吗？或者你应该使用反射吗？实体 => 转换器（使用反射）=> DTO？

顺便说一句，当你将Entity转换为DTO时，你应该使用第三个，transformer，class，还是调用Entity上的某些方法将自己转换为DTO（如$Invoice->toDetailDto()）？我认为调用->toDetailDto 是违反单一职责的，但另一方面，它解决了在不使用反射和没有数百个getter 的情况下访问实体的私有属性的问题。

Answer 1

有人可以澄清以下主题吗？

这不是你的错——文学很烂。

根据 DDD 的原则，域应该只关心自己而不关心周围的世界

是的，关于那个......这是一个谎言。除非有某种方法可以将信息重新输出，否则将信息注入对象是没有意义的。 （类比：/dev/null 是一个很棒的数据库，如果您不需要再次从中获取信息。）

“我如何从你那里获取信息？”是对象契约的一部分；合同的那一部分可能是您要求对象获取信息的问题，或者可能是对象将信息发送到“其他地方”，您可以查看那里。

例如货运演示，Cargo“聚合根”包含一个number of methods，用于将信息复制出对象。

对于像DTO 这样的东西，谜团的一部分是弄清楚域模型接口是否应该包含对 DTO 定义的依赖。最常见的答案是否定的：依赖项通常指向领域模型，而不是远离它。但是“不”不是唯一可能的答案。如果 DTO 定义是稳定的（例如，因为它是由某些行业标准定义的），那么与使用字符串或数字相比，您在那里遇到问题的可能性不会更大。

---

反思……这可能是正确的选择。如果没有任何变化，或者如果一切总是在锁定步骤中发生变化，那么反射就可以了。当您需要更改域模型的实现并保持 DTO 的定义稳定以免破坏客户端时，它可能会变得更加混乱，具体取决于代码中有多少不同的地方适用对领域模型的反射，以及你能否在时机成熟时找到它们。