在我看来，我们需要反转这里的构造。
实体依赖于服务来填充其内部的各种属性。这应该交给建筑商，不是吗？（这就是对象的构造）我正在查看遗留代码并执行一些一般的重构。
从本质上讲，这个实体应该是非常愚蠢的，似乎有多种处理正在进行，我非常确定应该/可能会被打破。
将服务注入域实体可能不是一个好主意，但可能不是出于您认为的原因。
本质上，这个实体应该非常愚蠢，似乎有正在进行的我很确定应该/可能会被破坏的处理出来
这是一个有争议的问题，但许多人认为哑域实体是一种反模式（贫血域模型），违背了面向对象的编程风格。实体不仅应该包含数据，还应该封装行为。
问题是，在域对象开始出现低内聚性之前，您可以添加多少行为？在您的示例中，依赖服务来填充各种属性是域对象的职责（内聚）和非职责之间的典型边界情况。此外，如果属性是从数据库显式加载的，这可能违反了持久性无知原则。
如果事实证明，这些属性需要从对象诞生之初就进行初始化，我同意您的观点，即Factory或Builder可能是获取数据和组装实体的更好地方，尤其是在构建逻辑复杂的情况下。
但通常，这样的机制是为了提供延迟加载，换句话说，是为了按需及时填充属性。这允许推迟昂贵的操作，例如从数据库中获取潜在的大数据，并避免从一开始就在内存中加载大对象图。
虽然我个人不会因为看到在构建时出于懒惰加载的目的在实体中注入服务而感到冒犯，但有些人认为这是一种糟糕的做法：请参阅此处。对于更干净、更可测试的实体，您可能更喜欢使用方法注入或委托注入。