我应该通过Aggregate root - Repository Pattern DDD来CRUD子集合

时间:2018-04-06 11:02:50

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

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

例如,如果我们有Products和Variants实体,则Product在这种情况下是Aggregate root,因此repo应仅适用于Product实体。
如果我们想要CRUD变种,我们应该通过产品回购来做到这一点 这是有道理的,因为没有产品,变体没有意义。

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

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

我的问题:
对于此管理页面后端
- 它的逻辑是否应该通过产品回购来访问变体? - 或者我们是否应该有另一个以Variant为根的单独聚合? - 或者我们是否应该破坏规则并为具有聚合根产品的Aggregate Variant创建一个repo?

这个例子可能很简单但实际上有许多实体在我们的系统中具有与变体相同的案例,例如股票,变量......,并且它们都需要与变体1相同的管理页面。

1 个答案:

答案 0 :(得分:0)

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

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

产品中需要(陈旧副本)变体状态的方法通常在方法签名中有一个“域服务”参数;域服务将具有接受变体标识符作为参数的方法,并返回该数据的最新副本。

通常在不参考产品的情况下管理Variant集合。