我听说聚合根取决于用例。但这在编码上下文中意味着什么？
您有一个服务类，它当然包含将在存储库中完成某事的方法(用例)。太好了，所以您使用相当于聚合根的存储库来执行查询。
现在您需要执行一些其他类型的操作，它使用与第一个服务类完全不同的用例但使用相同的实体。
此处表示:
实体:客户、订单、LineOrder
服务一:新增客户，删除部分客户，获取客户订单
此处聚合根似乎是 Customer，因为您需要此存储库来执行这些用例。
服务 2:从实际订单中检索客户
此处聚合根似乎是 Order，因为您需要此存储库来执行此用例。
如果我错了请指正。现在这意味着您有 2 个聚合根。
现在我的问题是，由于聚合根取决于用例，这是否意味着如果您最终有很多用例，我们最终可能会得到很多存储库？
上面的例子可能不是最好的例子……所以假设我们有一个 Journal，它包含 JournalEntries，每个条目包含 Tasks、Problems 和 Notes。 (这是在告诉系统对项目做了什么的情况下)
这是否意味着我最终会得到 2 个存储库？ (期刊，期刊条目) 在我需要从日记条目中添加新任务、问题和注释的用例中？ (可以看作是一种服务)
或者可能以 4 个存储库结束。 (日志、任务、问题、笔记) 在我需要访问指导任务、问题和注释的用例中？ (可以看做是另外一个服务)
但这是否意味着如果我需要这两种服务(实际上包含用例)，我实际上需要 5 个存储库才能在它们中执行用例？
谢谢。
最佳答案
您好，我看到了您的帖子，我想我可以给您我的意见。首先，我必须说我在项目中从事 DDD 已经三年了，所以我不是专家。但我目前正在一个项目中作为一名架构师在 DDD 中指导开发人员，我必须说这不是在公园散步......我不知道我已经重构了多少次模型和实体关系。
但我的经验是，您最终会得到一些存储库(不少但不是很多)。我的聚合通常包含几个类，聚合对象图并不那么深(如果您明白我的意思)。
但我尽量具体一点:
1) 聚合根由您的需要定义。我的意思是，如果您觉得您经常需要通过 Journal 访问 Tasks 对象，那么这可能是将其升级为聚合根的标志。
2) 但不可能所有事物都是聚合根，所以尽量封装紧密相关的对象。 Notes 看起来像是被根对象拥有的候选对象。您可能总是将 Notes 与根相关联，否则它会失去其上下文。笔记不能单独存在。
3) 请记住，聚合用于将大型复杂域拆分为较小的“岛屿”，以照顾其居民。重要的是不要让您的域比实际情况更复杂。
4) 在深入到项目实现阶段之前，您不知道模型的外观。如果您意识到某些存储库没有被经常使用，它们可能是合并到其他根对象的候选者(如果它们有那种关系)。您可以在没有其上下文的情况下通过根对象分解出经常使用的对象。我的意思是，例如，如果 Journal 是聚合根并且包含 Notes 和 Tasks。一段时间后，您的模型会增长，也许还有任务 与 Action 和 ActionHistory 以及 User 和 Rule and Permission 有关联。现在我只是在规则/操作/用户权限功能中抛出一堆 om 公共(public)对象。也许这会导致用例从另一个角度处理任务，“查看此用户执行的所有任务”等。任务更多地涉及某种状态/工作流引擎，因此可能成为聚合根本身。
好的。不是最好的例子，但它可能会给你想法。根对象可以包含子对象，其中一些子对象也可以是根对象，因为我们需要在另一个上下文(而不是日志)中使用它。 但是每次你用一个新模型启动时，我自己都会撞到墙上。顺其自然，让模型通过其客户/订阅者自行发展。您可以通过使用来完善模型。服务(应用程序服务而非域服务)当然通过响应 UI 和用例(通常是一对一)的方法进行扩展。
我希望我在某种程度上帮助了你......或者没有 :D
关于domain-driven-design - 聚合根取决于用例，那么这是否意味着我们最终可能会得到很多存储库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4862952/