我正在努力解决这个问题：如何判断一个概念是聚合根还是只是一个实体（这是 AR 的一部分）？ ：
也许如果我需要在其他 AR 中引用实体，那么我需要将其设为 AR：如果应用程序的某个地方我需要将某些内容链接到特定订单行，那么订单行将成为 AR。
或者它只是在生命周期方面，但如果是的话，我看不出在 AR 中有实体的意义：它只是价值对象。
或者可能是因为实体可以更改 AR，然后我将其推广为 AR。
【问题讨论】：
标签： entity domain-driven-design domain-model aggregateroot
看看下面Udi Dahan的博文和cmets。
从技术角度来看，AR 是一个交易边界。换句话说，一组应该始终保持一致的实体。极端的定义是，AR 甚至不需要有 ID。
从业务角度来看，它是您领域中的一个主要概念，它是通用语言的一部分，而实体并非必须如此。
例如，对于汽车销售公司来说，汽车是一种 AR，但引擎、车轮、轮胎等只是实体。但如果你用汽车制造能力扩展你的汽车销售公司的软件，那么：引擎、轮胎等：可能会在软件的那部分单独使用 AR。因此，如果您有一个销售汽车和制造汽车的软件，您有时会根据上下文使用不同的 AR。有些对象在一个地方是 AR，而在另一个地方是实体。 DDD 将此概念命名为“有界上下文”或“域”。
我认为您的困惑来自缺乏前期设计以及没有正确定义那些“有界上下文”。
【讨论】：
实体只能从 AR 中检索，不能从其他 AR 中引用。所以当你删除 AR 时，垃圾收集器也应该收集其中的所有实体/值对象。
我制作了一个 AR，我需要按一个（按 id）检索。您说（实体和 AR）都有 ID。如果实体有全局 id，则意味着您希望通过 id 检索它们，因此它们也应该是 AR。
实体示例可以是对帖子的回复。您想检索一篇帖子 (AR)，但您不按 id 检索回复，而是从帖子 AR 中获得回复。但是，如果您想对回复进行评分、删除、编辑或其他操作，那么它可能会变成 AR，因为您将希望在不先检索帖子的情况下检索它（以及其他回复，这将是一种开销）。
尝试创建小型 AR（内部没有大型实体树）。当您想从另一个 AR 引用 AR 时，请通过 VO id 进行操作，例如 FooAggregateId(1)。不要引用 AR 对象，否则您将不得不一次加载大量 AR，或者使用延迟加载。
【讨论】：