问题
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.
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.
回答1:
I'd like to complement the answer by CPerson.
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.
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.
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.
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.
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.
回答2:
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?
An Aggregate represents a consistency boundary. If an Entity is owned by an Aggregate and is required for ensuring consistency then it should be persisted with 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.
Yes, it would be. You can consider using an ORM if this is a real issue. The ORM will maintain in memory the graph rooted at your Aggregate Root and will ensure that changes are persisted as necessary.
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.
Try to think of your domain separately from your persistence strategy. You have a domain model that you map into a relational schema. The relational schema should not drive the design of the domain.
来源：https://stackoverflow.com/questions/60439844/how-entities-covered-with-in-an-aggregate-root-are-saved-in-ddd