Design patterns 在另一个存储库中使用一个存储库

我是DDD新手，我有一个合作伙伴聚合，其中有一个用户引用。 用户对象本身是另一个聚合

由于并非所有用户都必须在Partner对象中引用，因此User对象是聚合根。 合作伙伴也是聚合根

第一: 如果一个聚合根在另一个聚合根中，我的设计会出错吗

第二： 如果设计是正确的，那么在另一个存储库中使用一个存储库来持久化合作伙伴会是一种糟糕的做法吗？（PartnerRepository中的UserRepository）

Obs：我没有使用任何ORM框架

第一：我的设计中有一个聚合根是错误的吗 另一个

我对此表示怀疑。例如，

User

可以是称为用户管理的某个域的聚合根，

UserProfile

可以是称为用户配置文件的某个其他域的聚合根，并且两个域对象之间可能存在

1:1

关联

第二：如果设计是正确的，那么使用它会是一种不好的做法吗 在另一个存储库中保存合作伙伴？（用户存储库） 在PartnerRepository内）

你应该确保有一个明确的关注点分离，并遵循单一责任原则。也就是说，存储库可以处理单个域对象，而在另一个域对象中注入存储库则为处理相关或不相关的域对象打开了大门

我的建议是，您应该在域服务中表示事务，在那里您可以根据需要注入任意多的存储库

我是DDD的新手

我将从DDD的角度来回答这个问题，而不是OOP（面向对象编程）

第一：我的设计中有一个聚合根是错误的吗 另一个

它不会遵循领域驱动设计的一般准则。如果要从另一个聚合根引用一个聚合根，则应按id引用它

第二：如果设计是正确的，那么使用它会是一种不好的做法吗 在另一个存储库中保存合作伙伴？（用户存储库） 在PartnerRepository内）

同样，如果遵循DDD的指导原则，则不会这样做，而是使用单独的存储库分别持久化每个聚合

，可能是DDD领域中第二个更好解释的数字

第一：如果一个聚合根在另一个聚合根中，我的设计会出错吗

对

合计 一组相关对象，它们被视为一个单元，用于数据更改。外部引用仅限于聚合中指定为根的一个成员。在聚合的边界内应用一组一致性规则

您的设计面临的问题是：如果允许用户聚合独立修改相同的状态，则伙伴聚合无法保护其自身的不变量

在您的设计中，当您断言X是一个聚合时，您提出了两个声明

对X的任何更改的有效性都可以在不咨询任何外部状态的情况下确定

任何外部变更的有效性都可以在不咨询X状态的情况下确定

这就是聚合边界——外部的变化不需要看内部，内部的变化不需要看外部

因此，嵌套聚合是一个矛盾

表达相同想法的另一种方式是：如果一个聚合根在另一个聚合根中，那么就有一个聚合（伙伴聚合），它有两个根（伙伴实体和用户实体），这正是聚合模式要避免的情况

可能的补救办法：

一是用户实体实际上是合作伙伴聚合的一部分。对用户的每次更改都应该由合作伙伴管理。将用户移回伙伴聚合中，并阻止实现访问它，除非向聚合根发出命令

另一个原因是用户实体不是合作伙伴聚合的一部分。然后您消除了合作伙伴中的直接引用；这可能意味着完全消除引用（如果合作伙伴的业务规则根本不依赖于用户），或者拥有对用户标识符的引用，以及检查标识符而不遵循该标识符的业务规则（换句话说，您的规则可能会检查id引用是否为空/不为空，或者是否为集合的成员）. 仔细想想，合作伙伴聚合甚至无法判断它引用的用户是否存在

---

第三个是在模型中发现新实体，其中包括合作伙伴聚合实际用于验证的用户部分。这可能是用户状态的快照，也可能是将用户重构为多个部分。

感谢设计中的答案我的用户中有一个UserRole对象，这个UserRole引用了合作伙伴，因此当我插入合作伙伴时，我必须先插入没有用户的合作伙伴，这样我才能获得合作伙伴引用id，然后将用户持久化为UserRole。这就是为什么我需要在Partner Repository中添加UserRepository，以便它可以将Partner作为聚合处理插入。我想用户角色和用户关系的设计是设计中的一个棘手的部分。@MarcoPrado也许我弄错了，但在坚持合作伙伴之前，用户和角色都应该存在：OSorry我会尽力解释。一个用户可以连接到多个合作伙伴，因此每个UserRole必须对应于与合作伙伴的关系，这样每个用户可以有一个或多个UserRole，每个UserRole引用合作伙伴，但合作伙伴必须有一个用户，即拥有合作伙伴的用户，这种关系也通过用户中的用户角色来表示model@MarcoPrado顺便说一句，我不明白为什么你不能实现我在回答中已经解释过的一切。既然您说您没有使用OR/M，显然您需要实现一个