Domain driven design DDD-实体是否应该创建实体？

在我的域中，我可能有一个名为

User

的实体，它代表一个人和

Tenant

，一个代表企业的实体

有人可能会认为这是一个管理用户，因此，它应该能够注册新用户，就代码而言，这基本上可以转换为3种形式：
-

adminUserInstance.CreateUser（newUserDTO）

-
tenantInstance.CreateUser（newUserDTO）


-
newUserInstace.SelfSave（）

由于自注册，newUserInstace.SelfSave（）是必需的，其他两个有意义吗？我是否应该只保留自注册并转向从属模式，即同一用户可以是多个租户的一部分

广义而言：
问题
/
答案
应该由
用户创建还是自行创建，然后绑定到给定的
用户
？从更广泛的角度来看：实体是否应该拥有创建其他（而不是任何其他）实体的知识，或者这些实体应该能够创建自己，并让“请求者”调用将它们捆绑起来的域服务

更广泛地说：问题/答案应该由用户创建还是自行创建，然后绑定到给定的用户？从更广泛的角度来看：实体是否应该拥有创建其他（而不是任何其他）实体的知识，或者这些实体应该能够创建自己，并让“请求者”调用将它们捆绑起来的域服务

的技术指导是，您应该始终获得一个实体，并使用它创建新的实体。“客户不是凭空出现的。”

也就是说，创建聚合根实体很奇怪；不是“错”，但它偏离了将命令分派到要修改的聚合的常规模式
 
实体
可以由
实体
创建，但只能在同一个
集合
中创建。因此，如果一个
集合
创建了一个
实体
，那么该
实体
就是一个嵌套的
实体
；不能在聚合的
边界之外引用它。将嵌套的
实体的创建放在
聚合
中，因为
聚合
需要强制执行一些不变量，这是在设计
聚合
时要做的决定

另一方面，
aggregate root
（
AR
）由客户端代码创建（大多数情况下是
应用程序
服务）但是
AR
强制执行它自己的不变量！因此，在PHP代码中，应该如下所示：

//somewhere in an Application service
function createUser($id, $username, $password) 
{
     $user  = new User(); //an AR should always be new-able, i.e. with not injected dependencies

     $user->registerNew($id, $username, $password); //here the invariants are enforced

     $this->userRepository->addOrSave($user);
}

newUserInstance.SelfSave（）文件

聚合本身不会“保存”（持续）。这是
应用程序
服务的工作。无论如何，“save”似乎不是来自于您的通用语言，您需要一个更合适的名称（“register”？）