domain-driven-design - DDD - 实体应该创建实体吗？

Question

在我的域中，我可能有一个名为 User 的实体，它代表一个人和 Tenant，一个代表企业的实体。

有人可能会认为这是一个管理用户，因此，它应该能够注册新用户，这在代码方面将被翻译成基本上 3 种形式:
-adminUserInstance.CreateUser(newUserDTO);
-tenantInstance.CreateUser(newUserDTO)
-newUserInstace.SelfSave()

由于自助注册，newUserInstace.SelfSave() 是必需的，其他两个有意义吗？我是否应该只保留 self 注册并转向附属模型，其中同一用户可以是多个租户的一部分？

更广泛地说:Questions/Answers 应该由 Users 创建还是自己创建然后绑定(bind)到给定的 User？更广泛地说:实体是否应该拥有创建其他(而不是任何其他)实体的知识，或者实体应该能够创建自己并让“请求者”调用将它们捆绑在一起的域服务？

Answer 1

In broader terms: should Questions/Answers be created by Users or self created and then tied to a given User? and on even broader terms: Should entities hold the knowledge to create other (not any-others) entities or the entities should be able to create themselves and have the "requester", for example, call a domain service that will bundle them up?

Udi Dahan的技术指导是你应该总是得到一个实体，并用它来创建新的实体。 “客户不会凭空出现。”

也就是说，创建聚合根实体很奇怪；不是“错误”，但它偏离了将命令分派(dispatch)到您要修改的聚合的通常模式。