2

仍在阅读和学习 DDD 并尝试将其应用到我正在从事的项目中。我仍在尝试绕过聚合并遇到一个有趣的问题。

假设我有 2 个聚合,1 个具有根的帐户实体,另一个具有根的用户实体。

没有用户就无法创建帐户,但用户可以,这就是为什么它们都充当自己聚合的根。请注意,他们的聚合包括其他实体,但这对我的问题并不重要。

一些业务规则: 1) 创建帐户时,必须与用户关联。如果用户不存在,则必须先创建它。

2) 当一个帐户被删除时,其关联的用户也必须被删除。

3) 创建用户时,不需要与帐户关联。

3) 当一个用户被删除时,如果它与一个帐户相关联,它也必须被删除。

由于 Account 和 User 形成了它们自己的聚合,因此可能会有它们自己的 Repositories。这意味着标准的添加、删除、查找和删除方法将由每个存储库定义。

因此,鉴于这些情况,完成以下任务的最佳方法是什么: 1) 创建帐户时,我想我会在其用户属性上调用一个方法来验证用户是否存在。这是正确的吗?

2)删除帐户后,我如何也删除其关联的用户。从帐户存储库?但这不仅仅是在用户存储库中重复代码吗?或者存储库可以相互引用和调用吗?

3)当用户被删除时,确定它是否与帐户相关联并在不重复代码的情况下将其删除的最佳方法是什么(可能类似于第二个问题)。

我在某处读到,如果逻辑跨越两个实体或聚合,请考虑使用服务。但我对此并不满意,因为是什么阻止了客户端(假设 API 将得到发展,并且用户将在未来使用其他演示文稿)绕过服务并简单地调用存储库?

更新1:

刚刚意识到这可能是一个相关的问题:我应该如何强制聚合根之间的关系和约束?

4

1 回答 1

8

From DDD book, p128:

Any rule that spans AGGREGATES will not be expected to be up-to-date at all times. Through event processing, batch processing, or other update mechanisms, other dependencies can be resolved within some specific time.

Now, first you need to clearify it to yourself, with your domain experts, which of these rules is a true invariant, meaning - it must be immediately consisted. If there is such a rule, it should be enforced by an aggregate root, and in this case, you might consider merging these 2 aggregates into one. If there isn't such a rule, then, as stated above, eventual consistency will do. You might consider Domain Events for that purpose. see Udi Dahan's post

于 2012-03-29T11:13:50.743 回答