聚合根中子实体的目的是什么？

Question

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

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

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

1. 它具有本地聚合标识
2. 不能直接访问，只能通过聚合根访问
3. 应该有方法
4. 不应从聚合中暴露出来

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

1. 实体应该是私有的聚合
2. 我们需要一个只读副本 Value-Object 来公开来自实体的信息（例如，至少让存储库能够读取它以便保存到数据库）
3. 我们在实体上拥有的方法在 Aggregate 上重复（反之亦然，我们必须在 Aggregate 上拥有的处理实体的方法在实体上重复）

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

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

---

[更新以响应 Constantin Galbenu 回答和 cmets]

那么，实际上，你会有这样的东西吗？

public class Aggregate {
    ...
    private _someNestedEntity;

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

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

Answer 1

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

实体应该是私有的聚合

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

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

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

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

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

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

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

Answer 2

1. 实体应该是私有的聚合

是的。我不认为这是一个问题。继续阅读以了解原因。

1. 我们需要一个只读副本值对象来公开来自实体的信息（至少让存储库能够读取它以便 例如，保存到数据库）

没有。使您的聚合返回需要持久化和/或需要在聚合的每个方法的事件中引发的数据。

原始示例。现实世界需要更细粒度的响应，也许performMove 函数需要使用game.performMove 的输出来为persistence 和eventPublisher 构建propper 结构：

  public void performMove(String gameId, String playerId, Move move) {
    Game game = this.gameRepository.load(gameId); //Game is the AR
    List<event> events = game.performMove(playerId, move); //Do something
    persistence.apply(events) //events contains ID's of entities so the persistence is able to apply the event and save changes usign the ID's and changed data wich comes in the event too.
    this.eventPublisher.publish(events); //notify that something happens to the rest of the system
  }

对内部实体执行相同操作。让实体返回由于其方法调用（包括其 ID）而更改的数据，在 AR 中捕获此数据并为持久性和 eventPublisher 构建适当的输出。这样，您甚至不需要向 AR 公开带有实体 ID 的公共只读属性，而 AR 也不需要向应用程序服务公开其内部数据。这是摆脱 Getter/Setters 包对象的方法。

1. 我们在实体上拥有的方法在 Aggregate 上重复（反之亦然，我们在 Aggregate 上必须拥有的处理实体的方法 在实体上重复）

有时，要检查和应用的业务规则仅属于一个实体，其内部状态和 AR 只是充当网关。没关系，但如果你发现这种模式太多，那么这表明 AR 设计有误。也许内部实体应该是 AR 而不是内部实体，也许您需要将 AR 拆分为多个 AR（其中一个是旧的 ner 实体），等等......不要害怕拥有只有一个的类或两种方法。

回应dee zg cmets：

persistance.apply(events) 究竟做了什么？它能拯救整个 仅聚合还是实体？

两者都没有。聚合和实体是领域概念，而不是持久性概念；您可以拥有不需要一对一匹配您的域概念的文档存储、列存储、关系等。您不会从持久性中读取聚合和实体；您使用从持久性中读取的数据在内存中构建聚合和实体。聚合本身不需要持久化，这只是一个可能的实现细节。请记住，聚合只是一种组织业务规则的构造，它并不意味着是状态的表示。

您的事件具有上下文（用户意图）和已更改的数据（以及在持久性中识别事物所需的 ID），因此在知道的持久层中编写 apply 函数非常容易，即在关系数据库的情况下执行什么 sql 指令，执行什么以应用事件并持久化更改。

您能否提供示例何时以及为什么更好（甚至 不可避免？）使用子实体而不是单独的 AR 引用 其 Id 作为值对象？

您为什么要设计一个具有状态和行为的类并对其建模？

进行抽象、封装、复用等基本SOLID设计。如果实体具有确保操作的域规则和不变量所需的一切，那么该实体就是该操作的 AR。如果您需要实体无法完成的额外域规则检查（即实体没有足够的内部状态来完成检查或不自然地适合实体和代表什么），那么您必须重新设计；有时可能是对执行额外域规则检查的聚合建模并将其他域规则检查委托给内部实体，有时可能会更改实体以包含新事物。它过于依赖领域上下文，所以我不能说有一个固定的重新设计策略。

请记住，您不会在代码中对聚合和实体进行建模。您只需对具有行为的类进行建模，以检查域规则以及执行该检查和响应更改所需的状态。这些类可以充当不同操作的聚合或实体。这些术语仅用于帮助沟通和理解类在每个操作上下文中的作用。当然，您可能会遇到操作不适合实体的情况，您可以使用 V.O. 对聚合进行建模。持久性 ID 并且没问题（遗憾的是，在 DDD 中，在不了解域上下文的情况下，默认情况下几乎所有内容都可以）。

你想从比我解释得更好的人那里得到更多启发吗？ （不是以英语为母语是这些复杂问题的障碍）看看这里：

https://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-1 http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-2 http://blog.sapiensworks.com/post/2016/07/14/DDD-Aggregate-Decoded-3

Answer 3

1. 它具有本地聚合标识

从逻辑上讲，可能，但是用我们所拥有的持久性手段来具体实现这一点通常是不必要的复杂。

1. 我们需要一个只读副本值对象来公开来自 实体（至少让存储库能够读取它以便 例如，保存到数据库）

不一定，例如，您可以拥有只读实体。

问题的存储库部分已在another question 中得到解决。读取不是问题，有多种技术可以防止来自外部世界的写入访问，但仍然允许持久层直接或间接填充实体。

那么，为什么我们有一个实体而不是只有值对象呢？

您可能有些仓促地将关注点放在同一个篮子中，实际上略有不同

• 操作封装
• 聚合级别不变实施
• 读取权限
• 写入权限
• 实体或 VO 数据完整性

仅仅因为值对象最好是不可变的并且不强制执行聚合级别的不变量（尽管它们确实强制执行自己的数据完整性）并不意味着实体不能具有某些相同特征的微调组合.

Answer 4

这些问题在 CQRS 架构中不存在，其中写入模型（聚合）不同于读取模型。在扁平化架构中，Aggregate 必须公开读取/查询方法，否则将毫无意义。

1. 实体应该是私有的聚合

是的，这样你就清楚地表达了它们不是供外部使用的事实。

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

存储库是一种特殊情况，不应以与应用程序/演示代码相同的方式查看。它们可以是同一个包/模块的一部分，换句话说，它们应该能够访问嵌套实体。

实体可以被视为/实现为具有不可变 ID 和表示其状态的 Value 对象的对象，如下所示（在伪代码中）：

class SomeNestedEntity
{
    private readonly ID;
    private SomeNestedEntityImmutableState state;

    public getState(){ return state; }
    public someCommandMethod(){ state = state.mutateSomehow(); }
}

所以你看到了吗？您可以安全地返回嵌套实体的state，因为它是不可变的。 Law of Demeter 会有一些问题，但这是您必须做出的决定；如果你通过返回状态来打破它，你会让代码第一次更容易编写，但耦合会增加。

1. 我们在实体上拥有的方法在 Aggregate 上重复（反之亦然，我们必须在 Aggregate 上拥有的处理实体的方法在实体上重复）

是的，这保护了 Aggregate 的封装，也允许 Aggregate 保护它的不变量。

Answer 5

我不会写太多。只是一个例子。一辆车和一个齿轮。车是聚合根。齿轮是一个子实体