汇总根中包含的实体如何保存在DDD中？ [英] How entities covered with in an aggregate Root are saved in DDD?

问题描述

在阅读了很多文章之后，我意识到如果一个概念/上下文存在聚合根，那么我们需要为整个概念/上下文建立一个单一的存储库。

After reading lot of posts, I realised if an aggregate root exists for a concept/context, we need to have a single repository for that whole concept/context.

如果是这种情况，我会看到内部实体没有任何存储库。如果是这样，这些内部实体如何保存到数据库？

If thats the case, I see there won't be any repositories for the internal entities. If so, how these internal entities are saved to database?

我在聚合根下有许多内部实体。因此，想知道是否需要将内部实体的所有保存都保存在聚合根存储库下，它会变得肿。请提出在这种情况下可以采取的措施。

I have a many internal entities under the aggregate root. So, wondering If I need to have all the saving of the internal entities under the aggregate root repository, it's going to be bloated. Please suggest what can be done in this case.

此外，我的内部实体将在持久性级别进入各自的表。如果不允许我以这种方式存储内部实体，请纠正我。

Also, my internal entities will go to each table of their own at the persistence level. Please correct me if I'm not allowed to store internal entities this way.

示例

考虑我有一个餐馆作为总根。它可以对名为Review的实体进行分组。

Example
Consider I have a Restaurant as a aggregate root. It can group an entity named Review. A review exists for a restaurant and can’t exist without it.

在这里，如果评论是一个内部实体，并且餐厅有很多评论，那么评论将被保存在一个单独的表中。但是由于只有一个餐厅存储库可用于餐厅聚合根目录，因此如何/在何处处理保存评论。

Here if Review is an internal entity and there can be numerous reviews for a restaurant, Reviews will be saved in a separate table. But as there will be only one Restaurant Repository for Restaurant aggregate root, how/where to handle saving reviews.

推荐答案

这样的讨论往往没有意义，通常是没有意义的。每个案例都是特定于上下文的，很少涉及持久性问题。

Such discussions without going to the context are often meaningless. Each case is context-specific and it rarely boils down to an issue with persistence.

在上述案例中，我永远不会将Review建模为Restaurant集合中的实体。这不是一个持久性问题，它是一个建模问题。

In the mentioned case, I would never model Review as an entity in the Restaurant aggregate. It is not a persistence issue, it is a modelling issue.

那里有几本DDD书，我相信阅读几篇博客文章还不足以了解DDD的战略和战术模式。这些模式之一实际上就是聚合模式。简而言之，聚合是一致性边界。聚合始终是特定于上下文的（就像其他情况一样。）

There are a few DDD books out there and I believe that reading a few blog posts isn't enough to understand both strategic and tactical patterns of DDD. One of those patterns is indeed the Aggregate pattern. In short, an Aggregate is the consistency boundary. Aggregate is always context-specific (just as anything else).

如果您正在建立餐厅管理系统或食品配送系统的模型，则评论可能会在单独的上下文中进行。 。没有餐厅背景这样的背景。这就是边界上下文模式的重点。在您的示例中，可能是餐厅评论上下文。评论会发生什么与食物，营业时间和订餐无关。

If you are modelling a restaurant management system or a food delivery system, reviews would probably be in a separate context. There's no such context as the "restaurant context". That's the whole point of the Bounded Context pattern. In your example, it is, probably, the restaurant review context. What happens with reviews has nothing to do with food, opening hours and table bookings.

如果您建模的是TripAdviser之类的东西，基本上只有评论。在这种情况下，评论或多或少与所评论的内容无关。然后，您的模型就完全不一样了。

If you are modelling something like TripAdviser, you only have reviews, basically. In such a case, reviews are more or less agnostic to what is being reviewed. Then, your model is completely different.

评论的数量在不断增长，因此将所有评论作为一个实体进行某种程度的合计就没有多大意义。同样，聚合是一致性边界。您是否会说如果另一则评论是一颗星就无法发布评论？我不这么认为。您想要在餐厅总体中保护的关于评论的不变性是什么？您是否需要根据这些评论来限制更改餐厅状态的评论次数？我认为情况并非如此。因此，评论可能是一个汇总，因为所有评论都是彼此完全独立的。

The number of reviews is ever-growing, so putting all reviews as entities to some aggregate won't make much of a sense. Again, Aggregate is the consistency boundary. Would you say that a review cannot be posted if another review is one star? I don't think so. What is the invariant that you're trying to protect in the Restaurant aggregate, concerning reviews? Would you need to limit the reviews count of change the state of a Restaurant based on those reviews? I don't think it's the case. So, a review could be an aggregate on its own, since all reviews are completely independent of each other.

评论汇总中的餐厅可能是一个简单的价值对象，持有餐厅ID。在构造此价值对象时，您要确保给定的批评确实存在并且可以接受审查。当餐厅消失时，您确实需要清除评论。但这也是特定于上下文的。该餐厅可能会关闭，但您还是要保留评论。

A Restaurant in the review aggregate could be a simple value object that holds the restaurant id. On the construction of this value object, you'd ensure that the given restarant indeed exists and open for reviews. You would indeed be required to clear reviews when the restaurant disappears. But it is also context-specific. The restaurant might close but you keep the reviews anyway.

这篇关于汇总根中包含的实体如何保存在DDD中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！