domain-driven-design - 什么是聚合根？

Question

不，这不是重复问题。我有很多关于这个主题的资源，但我仍然觉得我没有完全理解它。

这是我目前掌握的关于什么是聚合和聚合根的信息(来自多个来源，无论是文章、视频等...):

• 聚合是多个值对象\实体引用和规则的集合。
• 聚合始终是命令模型(旨在更改业务状态)。
• 聚合代表(数据库——因为本质上更改将被持久化)工作的单个单元，这意味着它必须是一致的。
• 聚合根是与外部世界的接口(interface)。
• 聚合根必须在系统内具有全局唯一标识符
• DDD 建议每个聚合根有一个存储库
• 聚合中的简单对象不能在其 AR(聚合根)不知情的情况下更改

考虑到所有这些，让我们来看看我感到困惑的部分:

在this它说的网站

The Aggregate Root is the interface to the external world. All interaction with an Aggregate is via the Aggregate Root. As such, an Aggregate Root MUST have a globally unique identifier within the system. Other Entites that are present in the Aggregate but are not Aggregate Roots require only a locally unique identifier, that is, an Id that is unique within the Aggregate.

但是，在 this示例 我可以看到聚合根由一个名为 Transfer 的静态类实现，该静态类充当聚合，内部名为 TransferedRegistered 的静态函数充当 AR。

所以问题是:

1. 函数怎么可能是一个 AR，如果它必须有一个全局唯一的标识符，而没有，原因是它是一个函数。具有全局唯一标识符的是此函数产生的领域事件。
2. 以下问题 - 聚合根在代码中是什么样子的？是事件吗？是返回的实体吗？是聚合类本身的功能吗？
3. 如果函数返回的领域事件是 AR(如前所述，它必须具有全局唯一标识符)，那么我们如何与该聚合进行交互？第一篇文章明确指出，与聚合的所有交互都是由 AR 进行的，如果 AR 是一个事件，那么我们只能对其使用react。
4. 这样说聚合有两个主要工作是否正确:
   • 根据收到的输入和知道的规则应用所需的更改
   • 返回需要从 AR 持久化和/或需要在 AR 的领域事件中引发的数据

如果开头的任何要点都以某种方式错误，请纠正我，如果我遗漏了任何要点，请随时添加更多!

感谢您澄清问题!

Answer 1

I feel like I don't fully understand it.

那不是你的错。文学很烂。

据我所知，使用领域驱动设计实现解决方案的核心思想大约在 2003 年来自 Java 世界。因此 Evans 在蓝皮书第 5 章和第 6 章中描述的模式被理解为面向对象的(在 Java 意义上)域建模正确。

第 6 章讨论聚合模式，专门讨论生命周期管理；您如何在域模型中创建新实体，应用程序如何找到合适的实体进行交互，等等。

所以我们有 Factories，它允许您创建领域实体的实例，还有 Repositories，它提供了一个抽象来检索对领域实体的引用。

但是还有第三个谜题，那就是:当您的域中有一些规则要求域中的两个实体之间进行同步时会发生什么？如果您允许应用程序以不协调的方式与实体对话，那么最终可能会导致数据不一致。

所以聚合模式就是对此的回答；我们将协调的实体组织成图表。关于更改(和存储)，实体图成为允许应用程序与之交互的单个单元。

聚合根的概念是应用程序和图之间的接口(interface)应该是图的成员之一。因此，应用程序与根实体共享信息，然后根实体与聚合的其他成员共享该信息。

聚合根作为聚合的入口点，起到粗粒度锁的作用，确保对聚合成员的所有更改同时发生。

将此视为一种封装形式并非完全错误——对于应用程序而言，聚合看起来像一个单一实体(根)，聚合的其余复杂性从 View 中隐藏。

现在，在过去的 15 年中，出现了一些语义漂移；人们试图以更适合他们的问题或更适合他们喜欢的设计的方式调整模式。因此，您必须谨慎设计如何翻译他们正在使用的标签。