Reverse relationships for smaller/better Aggregates?

Question

Let's take an example: we have two related entities, like Question and Choice. This is a poll: it contains of single question that may have 2 or more choices. Each choice can be voted for by users, each vote is stored.

Obviously, on paper, Question would contain a collection of Choices. And probably we would have something like this:

public class Question {
    List<Choice> choices;
    public void assignChoice(Choice choice) {}
    public List<Choice> getChoices();
}

Question is an Aggregate that contains list of other entity, Choice.

Now, if the Choice is a value object, I would be fine. Repository should store the aggregate starting from root, so it would store a root entity and related value objects.

However, here we have aggregate of entities! In that sense I wonder: why do we need to maintain collection in Question at all? I mean, for view, we will have query read-only model. For commands we might not needed it at all.

So we can move from this:

Question question = new Question("Favorite color?");
question.assignAnswer(new Choice("red"));
question.assignAnswer(new Choice("blue"));

questionRepository.store(question);

to:

Question question = new Question("Favorite color?");
Choice c1 = new Choice(question, "red"); // or just: questionId instead of question?
Choice c2 = new Choice(question, "blue");// the same

questionRepository.store(question);
choiceRepository.store(c1, c2);

Now we do not need to 'assign' anything to the Question and we don't need to maintain the collection. For example, this collection may vary - it may be collection of just approved choices, or voted choices, or top 3 voted choices etc. We are not able to expressed what kind of relationship is that just by having getChoices().

So should we even go further to have a rule like:

Don't compose Aggregates with other Entities. Just have a root Entity and value objects. Use reverse relationship to express the connection between aggregate roots.

Make sense?

Answer 1

In my opinion, one reason to let the Question be the aggregate root of the choices (and maintain a list of choices within the question) might be:

A choice does not exist on its own and is always related to a specific question (even as an entity). That's why I think it would make sense to access a choice only through its parent question.

Another advantage could be that whenever you change the question, you can easily check all related choices for invariants. Or when deleting the question, you can simply remove all child choices within the Delete operation of the question itself.

I agree that all of this could also be achieved via a reverse relation, but would be more complicated in my opinion. For example, if I would have a reverse relation and want to delete a question, I would have to iterate through all choices to pick the ones that are related to this specific question.

Concerning your point with the varying collections of choices inside the question: This is something were you could add some additional filter logic and in that way implement some domain logic within your question, like:

public class Question {
List<Choice> choices;
public List<Choice> getHighestVotedChoices();// will query choices and return highest voted choices
public List<Choice> getApprovedVotedChoices(); // will filter choices list "approved property"

}

Answer 2

Choice has Reference to Question

Makes sense if this is a composite, vice an aggregate.

Inadequate Requirements Analysis

Don't compose Aggregates with other Entities. Just have a root Entity and value objects. Use reverse relationship to express the connection between aggregate roots.

Make sense?

No, it does not.

It's not possible to make such global, absolute, diktats. Your requirements, use cases, will inform the class hierarchies and relationships.

it may be collection of just approved choices, or voted choices, or top 3 voted choices etc. We are not able to expressed what kind of relationship is that just by having getChoices()

Sounds like the Choice class needs Approved and Votes properties. Now, getting the "top 3 voted choices" would be quite easy.

Consider: class Choice : IComparable<Choice> then you can Sort() a List<Choice> based on Votes

I agree that all of this could also be achieved via a reverse relation, but would be more complicated in my opinion. For example, if I would have a reverse relation and want to delete a question, I would have to iterate through all choices to pick the ones that are related to this specific question.

So what if a collection must be iterated. That's what they're for. The .net framework goes to a lot of trouble to help you do this in a whole lot of ways.

Besides, you do not have to "iterate throught all choices", because Question has a choices property. So, select a choice to delete, get its Question reference, get that question's choices reference. Now you have all the choices.

Class design is not database design

Choice c1 = new Choice(question, "red"); // or just: questionId instead of question?

This, et.al. sounds like you want your class design to reflect the database design. Consider this stackoverflow question