[阅读了大量文章后，我意识到如果一个概念/上下文存在一个聚合的根，我们需要为整个概念/上下文建立一个单一的存储库。
如果是这种情况，我会看到内部实体没有任何存储库。如果是这样，这些内部实体如何保存到数据库？
我在聚合根目录下有许多内部实体。因此，想知道是否需要将所有内部实体保存在聚合根存储库下，它会变得肿。请提出在这种情况下可以采取的措施。
此外，我的内部实体将在持久性级别进入各自的表。如果不允许我这样存储内部实体，请更正我。
示例考虑我有一家餐馆作为总根。它可以对名为Review的实体进行分组。有一家餐厅的评价，没有餐厅的评价就不会存在。
如果评论是一个内部实体，并且餐厅可能有很多评论，则评论将保存在单独的表格中。但是由于只有一个餐厅存储库可用于餐厅聚合根目录，因此如何/在何处处理保存评论。
如果是这种情况，我会看到内部实体没有任何存储库。如果是这样，这些内部实体如何保存到数据库？
聚合表示一致性边界。如果实体归聚合所有，并且需要确保一致性，则该实体应与聚合根一起保留。
因此，想知道是否需要将内部实体的所有保存都保存在聚合根存储库中，这将变得肿。
是的。如果这是一个实际问题，则可以考虑使用ORM。 ORM将在内存中维护以“聚合根”为根的图形，并确保在必要时保留更改。
此外，我的内部实体将在持久性级别进入各自的表。如果不允许我这样存储内部实体，请更正我。
尝试将您的域与持久性策略分开考虑。您有一个映射到关系模式的域模型。关系模式不应驱动域的设计。
我想补充CPerson的回答。
没有上下文的这种讨论通常是没有意义的。每种情况都是特定于上下文的，很少将其归结为持久性问题。
在上述情况下，我永远不会将Review建模为Restaurant集合中的实体。这不是持久性问题，而是建模问题。
[那里有几本DDD书，我相信阅读一些博客文章不足以了解DDD的战略和战术模式。这些模式之一实际上就是聚合模式。简而言之，聚合是一致性边界。聚合始终是特定于上下文的（就像其他任何事物一样。）
如果您要为餐厅管理系统或食品配送系统建模，则评论可能会在单独的上下文中进行。没有“餐厅环境”这样的环境。这就是“边界上下文”模式的重点。在您的示例中，可能是餐厅评论上下文。评论发生的事情与食物，开放时间和订餐无关。
[基本上，如果您正在建模TripAdviser之类的东西，则只有评论。在这种情况下，评论或多或少与所评论的内容无关。然后，您的模型将完全不同。
评论的数量在不断增长，因此将所有评论作为一个实体进行汇总不会有太大的意义。同样，聚合是一致性边界。您是否会说如果另一则评论是一颗星就无法发布评论？我不这么认为。关于评论，您要在餐厅总体中保护的不变性是什么？您是否需要根据这些评论来限制更改餐厅状态的评论数？我认为情况并非如此。因此，评论可能是一个单独的汇总，因为所有评论都是彼此完全独立的。
评论汇总中的餐厅可以是保存餐厅ID的简单值对象。在构造此价值对象时，您要确保给定的批评确实存在并且可以接受审查。当餐厅消失时，您确实需要清除评论。但这也是特定于上下文的。餐厅可能会关闭，但您还是要保留评论。