我应该通过聚合根 CRUD 子聚合 - 存储库模式 DDD答案

【问题标题】：Should I CRUD the child Aggregates through Aggregate root - Repository Pattern DDD我应该通过聚合根 CRUD 子聚合 - 存储库模式 DDD
【发布时间】：2018-04-06 11:02:49
【问题描述】：

我正在阅读一些文章并观看一些教程来更新我的 DD 知识，他们都提到我们应该为聚合根实体构建存储库，这对我来说很有意义。

例如，如果我们有 Products 和 Variants 实体，在这种情况下 Product 是 Aggregate 根，因此 repo 应该只针对 Product 实体。
如果我们想对变体进行 CRUD，我们应该通过产品仓库来实现。
这是有道理的，因为没有产品，变体就没有意义。

现在在系统的管理部分，我们将需要一个仅用于变体的管理页面，以让管理员添加/编辑变体，在这种情况下与任何产品无关。
例如，管理员需要添加变体，例如：
- 颜色：红色
- 尺码：XL - ..

然后在创建产品时，他们可以将这些变体附加到新产品中。

我的问题：
对于此管理页面后端
- 它的逻辑是否应该继续通过 Products repo 访问 Variants？
- 或者我们应该有另一个以 Variant 为根的单独聚合？
- 还是我们应该打破规则并为具有聚合根产品的聚合变体创建一个存储库？

这个例子可能很简单，但实际上有许多实体与我们系统中的变体具有相同的大小写，例如股票、变量等，它们都需要与变体相同的管理页面。

【问题讨论】：

管理后台将是一个单独的有界上下文，您可能不必使用 DDD，一个简单的 CRUD 应用程序就可以了
@wolverine 是的，您是对的，我认为这是正确的答案，有时我们在阅读某个主题时会发生这种情况，而您完全忘记了在该特定概念之外还有一个世界
@AmrElgarhy 感觉有 2 个有界上下文 - 变体是管理后端中的实体 - 但作为值对象添加到产品中
@ChrisMoutray yes 对我来说也很有意义

标签： domain-driven-design ddd-repositories aggregateroot

【解决方案1】：

如果 Product 聚合的不同实例需要共享有关特定 Variant 的数据，则需要在 Product 聚合之外考虑 Variant。

因此，您通常会发现您有一个产品存储库，其中产品可能包含对变体标识符的引用，可用于在必要时查找变体。

Product 中需要（过时的副本）其变体状态的方法通常在方法签名中具有“域服务”参数；域服务将具有接受变体标识符作为参数并返回该数据的最新副本的方法。

Variant 集合的管理通常无需参考 Products。

【讨论】：