DDD: How to refer/select a value object inside aggregate?

Question

We have an aggregate of:

• entity: Poll (representing a question)
• two or more value objects Choice

Adding choices is done through Poll, repository stores only the aggregate, i.e. everything is done as expected.

Now, I need to select specific Choice that user chose. From the UI I will have only the choiceId of selected choice. So would my Poll.voteForChoice() method be:

• voteForChoice(choiceId) - where I pass the choice id to the aggregate root, so he iterates it's choices and finds the target choice so to increment the count. However, we are using ID here for the choice, and choice is value object.
• voteForChoice(Choice) - where we are sending the full value object, meaning I need to create it first before I do the voting. That also means I will need to have a Repo for choices, and they are value objects, so that clashes with all what I've learned ;)
• or it should be: Poll.getChoice(choiceId).vote().
• or the Choice is actually an entity, so we would use Repository to fetch choice: ChoiceRepo.find(id).vote().

Simple case, but what is the correct answer in DDD world?

• Alexander Langer: If Choice has an ID, why is it a value object and not an entity within Poll?
• Euphoric: Is it possible to add/remove questions after there are already votes in?
• lawpert: Hey @Euphoric, good question! Let's say once when poll is 'published', we can not change the choices.
• Alexander Langer: @lewpert, whether it has a database ID is irrelevant (value objects can have database ids for technical reasons). If you can refer to specific choices within a poll by their ID, they clearly have a (local) ID and it seems like choices are in fact (local) entities within the Poll aggregate root.
• Alexander Langer: It can probably make sense to allow to fix spelling mistakes or typos in a Choice after the poll has been started, while the current vote counts shall remain intact. This is a strong indication that choices are entities in the poll AR. You might want to recall the Car/Wheel exmaple in the blue book.

Answer 1

Depending on the collaborative degree of your application, you might find yourself in trouble if 2 or more users try to increment the same Choice concurrently. That will happen whether it's a VO or an Entity in the same Aggregate as the Poll.

To me the natural consistency boundary implied by the domain action of voting includes the user. So I would suggest a full fledged PollChoice Aggregate Root with a link to the User, or if there are multiple choices per poll, a PollResponse AR containing all choices (which can then be VO's) made by a particular user to a specific poll.

Edit : something along these lines

class PollResponse {
 int pollId;
 int userId;
 Choice choice;
 Datetime dateResponded;
}

• lawpert: It make sense... The choice is made by a user, so it make sense to have PollsUser that actually is making a choice on a poll. But isn't the concurrency problem still persist?
• guillaume31: No, a separate PollResponse AR would be created for each user, so changes would be totally isolated. You wouldn't have this "crowd effect" with the same Aggregate being updated by tons of users. (see my edit)
• guillaume31: It's a good idea to model your Aggregates as consistency boundaries for domain transactions. Voting for a poll normally doesn't require to affect other users' votes, so you might as well model that and include the user to further reduce the consistency boundary.

Answer 2

I believe that a value object should be referred by its value because that's what makes it unique, neither a GUID nor a local ID.

Consider a real world example

1) What web browser do you use at work?

• A) Chrome
• B) Firefox
• C) Internet Explorer
• D) Opera
• E) Safari

2) What web browser do you use at home?

• A) Chrome
• B) Firefox
• C) Internet Explorer
• D) Opera
• E) Safari

How would you vote in the real world? You would probably say something along the lines "For the first poll I vote for 'Firefox'" or "For the second poll I choose 'A'". Hence, there are few ways you can go about modeling the voting behavior

// 1st poll (GUID = 1)
Poll poll1 = pollRepo.find(1);
// 2nd poll (GUID = 2)
Poll poll2 = pollRepo.find(2);
poll1.voteForChoice("Firefox");
poll2.voteForChoice("Chrome");

On the other hand, there's nothing wrong in creating an instance of a value object outside the scope of its aggregate without using a repository

poll1.voteForChoice(new Choice("Firefox"));
poll2.voteForChoice(new Choice("Chrome"));

So, it seems like you can use the second option for the voteForChoice method. The first one uses ID which suggests that Choices be modeled as entities. The third one feels wrong like a leaky abstraction and breach of encapsulation. The forth one is wrong because of using a repository for a value object.

UPDATE

Important point. There's no a single recipe how to model your domain even if it's a common case in the real world. You may design your Choices as value objects and have a Map<Choice, Counter> choices property in your Polls. Or, you may design it as entities and have the counter as a part of a Choice. Additionally, you might want to have a List<User> users collection in the Choice entity to keep a track of users who voted for a particular Choice.

I know I've made it even more confusing for you, but the thing that I want to emphasize is that you have to decide for yourself what kind of domain model you need. My answer was based on the assumption derived from your question that value objects is what you need.

UPDATE 2

It turns out that according to Eric Evans when you tempted to create some sort of identifier for a value object even if it's a local one you should consider making it an entity instead.

• lawpert: +1 for excellent example. So we can say that value object is unique (by value) inside its boundaries, right? Like here, Choice has no meaning outside the Poll, therefore, Choice value object is unique inside the Polls boundaries.
• zafarkhaja: Yes, that's correct. But beware that true value objects are interchangeable. You should be able to use the same instance of Choice for different Polls because it's not the identity that matters, but the value.
• lawpert: Ok, but wait, if Choice e.g. contains number of votes, then this number becomes part of the value, and it can not be interchangeable, right?
• zafarkhaja: Right. All depends on how you wish to model it. Besides the fact that value objects don't have clear identity, they also don't have state and life-cycle. So if you want a Choice to have a state and a life-cycle you'd probably consider implementing it as an entity. Use this link as a reference.
• Alexander Langer: You seem to confuse the meaning of entities, value objects and aggregate roots. If it has a local identity, it's still an entity in the Poll aggregate boundary.