DDD - 实体是否应该创建实体？

在我的域名中，我可能会有一个名为User的实体，它代表一个人，代表一个企业的实体Tenant。DDD - 实体是否应该创建实体？

有人可能会认为这是一个管理用户，因此，它应该可以注册新用户，这在代码方面将被转换为主要3种形式：
- adminUserInstance.CreateUser(newUserDTO);
- tenantInstance.CreateUser(newUserDTO)
- newUserInstace.SelfSave()

作为newUserInstace.SelfSave()由于自注册的必要性，其他两个是否有意义？我是否应该只保留自我注册并转向所属机构模式，同一用户可以成为多个租户的一部分？

从更广泛的角度来看：应该Questions/Answers创建Users或自我创建，然后绑定到给定User？甚至更广泛的术语：实体是否应该掌握创建其他（而非任何其他）实体的知识，或者实体是否应该能够创建自己并拥有“请求者”，例如，调用将绑定它们的域服务？

来源

2017-06-12 Leonardo

从更广泛的角度来看：应该由用户创建问题/答案还是自己创建，然后绑定到给定的用户？甚至更广泛的术语：实体是否应该掌握创建其他（而非任何其他）实体的知识，或者实体是否应该能够创建自己并拥有“请求者”，例如，调用将绑定它们的域服务？

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

这就是说，创建聚合根实体是很奇怪;不是“错误的”，但它偏离了将命令调度到要修改的聚合的通常模式。

来源

2017-06-13 00:50:50 VoiceOfUnreason

Entities可以通过entities创建，但只在同一个aggregate之内。因此，如果aggregate创建entity那么entity是嵌套的entity;它不能在aggregate's边界之外被引用。因为aggregate需要强制执行一些不变量，所以将entities中嵌套的entities的创建置于aggregate之内，并且这是在设计Aggregates时作出的决定。

在另一方面，aggregate roots（AR）是由客户端代码（在大多数情况下Application服务）但的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); 
}

newUserInstace.SelfSave（）

的aggregate没有 “保存”（持续存在）本身。这是Application服务的工作。无论如何，“保存”似乎不是来自你的无处不在的语言，你需要一个更加适当的名字（“注册”？）。

来源

2017-06-13 08:09:03

DDD - 实体是否应该创建实体？

回答

相关问题