domain-driven-design - 聚合根中子实体的目的是什么？

Question

[从这个问题和评论跟进:Should entity have methods and if so how to prevent them from being called outside aggregate ]

正如标题所说:我不清楚实体作为一个 child 的实际/确切目的是什么？

根据我在很多地方读到的内容，这些是聚合子实体的属性:

它具有本地身份以聚合

它不能直接访问，只能通过聚合根

它应该有方法

它不应该从聚合

中暴露出来。

在我看来，这意味着几个问题:

实体应该是私有(private)的才能聚合

我们需要一个只读副本 Value-Object 来公开来自实体的信息(例如，至少存储库能够读取它以便保存到数据库)

我们在实体上拥有的方法在 Aggregate 上重复(反之亦然，我们必须在 Aggregate 上拥有的处理实体的方法在实体上重复)

那么，为什么我们有一个实体而不是只有值对象呢？只有值对象、聚合和公开值对象的所有方法(我们已经复制实体信息)似乎更方便。

PS。
我想关注子实体的聚合，而不是实体的集合。

[更新响应 康斯坦丁·加尔贝努 回答和评论]

所以，实际上，你会有这样的东西吗？

public class Aggregate {
    ...
    private _someNestedEntity;

    public SomeNestedEntityImmutableState EntityState {
       get {
          return this._someNestedEntity.getState();
       }
    }

    public ChangeSomethingOnNestedEntity(params) {
       this._someNestedEntity.someCommandMethod(params);
    }
}

Answer 1

您正在考虑数据。停下。 :) 实体和值对象不是数据。它们是您可以用来为问题域建模的对象。实体和值对象只是对问题进行建模时自然出现的事物的分类。

Entity should be private to aggregate

是的。此外，对象中的所有状态都应该是私有(private)的，并且不能从外部访问。

We need a read only copy Value-Object to expose information from an entity (at least for a repository to be able to read it in order to save to db, for example)

不，我们不会公开已经可用的信息。如果信息已经可用，这意味着有人已经对此负责。所以联系那个对象为你做事，你不需要数据!这本质上就是 Law of Demeter告诉我们。

经常实现的“存储库”确实需要访问数据，你是对的。他们是一个糟糕的模式。它们通常与 ORM 结合使用，在这种情况下甚至更糟，因为您失去了对数据的所有控制权。

Methods that we have on entity are duplicated on Aggregate (or, vice versa, methods we have to have on Aggregate that handle entity are duplicated on entity)

诀窍是，你不必这样做。您创建的每个对象(类)都是有原因的。如前所述，为了创建一个额外的抽象，对域的一部分进行建模。如果你这样做，一个存在于更高抽象级别的“聚合”对象将永远不想提供与下面的对象相同的方法。这意味着没有任何抽象。

这种用例仅在创建除了保存数据之外几乎没有其他作用的面向数据的对象时出现。显然，如果您无法获取数据，您会想知道如何处理这些数据。然而，这是一个很好的指标，表明您的设计尚未完成。