Domain driven design DDD-聚合根作为工厂是否正常？

我的聚合根可以充当他管理的实体的工厂吗

---

例如：我的聚合根“问题”可以实例化一个实体“答案”吗？

是的，如果代码是一个简单的

新答案（someArguments，…）

如果这是一个更复杂的过程，那么您应该将此代码提取到

AnswerFactory

类中

编辑： 创建干净代码的愿望决定了这一点，而不是DDD。DDD中与您的问题相关的一条规则是域（因此域层中的所有类）不应依赖于任何其他层（如基础设施或应用程序）

我的聚合根可以充当他管理的实体的工厂吗

差不多

聚合根不是实体本身，而是由实体扮演的角色。Think interface—它为应用程序提供了对域模型的受限访问，封装了实际实现

总的来说，对自己的状态负责是很自然的；毕竟，聚合的所有组件都将从相同的数据模型中提取（它们被持久化在一起）

在实体中（作为聚合根），您希望代码尽可能与域的语言保持一致。这通常意味着您没有设计模式中的“工厂”，而是在模型中有一些实体来生成托管实体

乌迪·达汉（Udi Dahan）在写作时有点间接地谈到了这一点

客户不是凭空出现的

模型中的实体都来自模型中的其他实体。一路下来的海龟

因此，将工厂设计模式引入领域语言有点简单

---

因为域模型存在于内存中。。。因为域模型有副作用是不寻常的。。。抽象连接点的许多常见动机并不适用。例如，如果您发现自己想要在域模型中注入一个模拟以进行单元测试，那么就出现了严重错误（是的，进入域服务，但不进入实体）。

工厂应该位于基础架构中。。。这是否意味着我应该引用该项目，或者该工厂应该由存储库（检索对象时）和/或其他工厂（创建新根时）注入？@Leonardo那么，从域到基础结构都有依赖关系，这就是bad@Leonardo你永远不会在聚合中注入任何东西。我建议的

AnswerFactory

类来自域层，它是由

Question

聚合使用

new

操作符创建的。如果

Answer

实体需要来自外部的信息，则该信息由客户机代码使用

Question

聚合上的方法传递，该聚合创建

Answer

实体，而不是注入工厂类。