阅读大量帖子后，我意识到如果某个概念/上下文存在聚合根，我们需要为整个概念/上下文创建一个存储库。
如果是这样，我认为内部实体不会有任何存储库。如果是，这些内部实体如何保存到数据库中？
我在聚合根目录下有许多内部实体。所以，想知道如果我需要在聚合根存储库下保存所有内部实体，它会变得臃肿。请建议在这种情况下可以做什么。
此外，我的内部实体将在持久性级别访问它们自己的每个表。如果不允许我以这种方式存储内部实体，请纠正我。
示例
考虑我有一家餐厅作为聚合根。它可以对名为 Review 的实体进行分组。评论存在于餐厅，没有评论就无法存在。
如果评论是一个内部实体，并且餐厅可以有许多评论，评论将保存在单独的表中。但由于餐厅聚合根只有一个餐厅存储库，因此如何/在哪里处理保存评论。
【问题讨论】：
标签： domain-driven-design aggregate ddd-repositories aggregateroot dddd
如果是这样，我认为内部实体不会有任何存储库。如果是，这些内部实体如何保存到数据库中？
聚合表示一致性边界。如果一个实体由一个聚合拥有并且需要确保一致性，那么它应该与聚合根一起持久化。
所以，想知道我是否需要将所有内部实体的保存都保存在聚合根存储库下，它会变得臃肿。
是的，会的。如果这是一个真正的问题，您可以考虑使用 ORM。 ORM 将在内存中维护以聚合根为根的图，并确保在必要时保留更改。
此外，我的内部实体将在持久性级别访问它们自己的每个表。如果不允许我以这种方式存储内部实体，请纠正我。
尝试将您的域与您的持久性策略分开考虑。您有一个映射到关系模式的域模型。关系模式不应驱动域的设计。
【讨论】：
我想补充 CPerson 的回答。
这种不深入上下文的讨论通常是毫无意义的。每个案例都是特定于上下文的，很少归结为持久性问题。
在上述情况下，我绝不会将 Review 建模为 Restaurant 聚合中的实体。这不是持久性问题，而是建模问题。
那里有几本 DDD 书籍，我相信阅读几篇博客文章不足以同时了解 DDD 的战略和战术模式。其中一种模式确实是聚合模式。简而言之，聚合是一致性边界。聚合始终是特定于上下文的（就像其他任何东西一样）。
如果您正在为餐厅管理系统或送餐系统建模，评论可能会在单独的上下文中。没有像“餐厅环境”这样的环境。这就是有界上下文模式的重点。在您的示例中，它可能是餐厅评论上下文。评论发生的情况与食物、营业时间和餐桌预订无关。
如果您正在为 TripAdviser 之类的东西建模，那么基本上您只有评论。在这种情况下，评论或多或少与正在评论的内容无关。那么，你的模型就完全不同了。
评论的数量不断增长，因此将所有评论作为实体进行汇总并没有多大意义。同样，聚合是一致性边界。如果另一条评论是一星，您会说无法发布评论吗？我不这么认为。关于评论，您试图在 Restaurant 聚合中保护的不变量是什么？您是否需要限制评论数量以根据这些评论更改餐厅的状态？我不认为是这样。因此，评论本身可以是一个汇总，因为所有评论都完全相互独立。
评论聚合中的餐厅可以是一个包含餐厅 ID 的简单值对象。在构建此值对象时，您将确保给定的餐厅确实存在并开放供评论。当餐厅消失时，您确实需要清除评论。但它也是特定于上下文的。餐厅可能会关门，但您仍然保留评论。
【讨论】：
我同意其他答案中提出的一些观点，即您可能不想那样建模，但我认为您的问题本身尚未得到回答。举个例子，它完全没问题。
所以这里是：
您不会为实体创建存储库（如在 DDD 存储库中），只为聚合根创建。 所以在你的例子中，应用层可能是这样的：
Restaurant restaurant = restaurantRepository.findById(23)
restaurant.addReview(review)
restaurantRepository.save(restaurant)
还要注意，操作是在聚合根上完成的。 所以一般来说，你的应用层中的命令通常是：加载聚合，对其执行操作，保存它
聚合被保存为一个整体和实体。 存储库背后发生的事情取决于您的基础架构。当然，由于存储库属于域，我们不关心那里的基础设施。
那么基础设施层中的实现（这些只是可能的一些示例）：
如果您有一个 RDBMS，您确实希望将实体存储在它们自己的表中。在这里你可以使用：
也看看这个question
此外，在某些情况下，您可能会仅出于技术原因拆分聚合。如果您要拥有一个包含大量实体的聚合，并且处理它变得很重，那么您可能希望纯粹出于技术原因将其拆分为两个聚合。但这是你尽量避免的事情，并且只在真正必要时才这样做。
【讨论】：