Could Vote, in this case be considered an “aggregate” and be deserving
of its own repository and aggregate status?

I think this might be the right answer. An aggregate should be a transactional consistency boundary. Is there a consistency requirement between votes on a match? The presents of a Vote collection on a Match aggregate would suggest that there is. However, it seems like one vote has nothing to do with the next.

Instead, I would store each vote individually. This way you can use the aggregate functionality of MongoDB to get the count, though I’m not sure whether it is still slow. If it is, then you can aggregate using the Map/Reduce functionality.

More generally, this may not be a best fit for DDD. If the domain doesn’t consist of complex behavior there is hardly a reason to try to adapt the DDD tactical patterns (entity, agreggate) to this domain.

First of all, DDD is really about creating a model where reading the code is like how the actual domain experts would be talking about the domain.

Second, they way DDD describes an aggregate root, the child objects on the aggregate root are merely properties on the aggregate root itself, and you shouldn’t be able to access the child elements directly, only through the aggregate root.

So seen from a DDD perspective, if votes are children to the aggregate root “match”, then the act of adding a vote to a match is actually an act of modifying the match.

Though you have not given enough information for me to fully understand the domain, it doesn’t seem to me that this would be the natural way to see things, but I imagine that it has some similarities to StackExchange?

On any StackExchange site, if I open my user page, I can see a list of votes I have cast, including if it is an up- or a downvote, and the time when I cast the vote. This is a direct query on votes I have cast. Thus, if you were to make a DDD model of StackExchange, then questions and answers could NOT be considered aggregate roots containing votes.

In this case, votes would be entities themselves.

Note that here I’m very focused on the way that “the blue book” describes aggregates, mainly because you mentioned it, and you focus on DDD in the question description. That doesn’t mean that this is the only/correct way of dealing with aggregates.

p.s. If you havn’t read the book yet, this presentation touches a lot of the subject matter: http://www.infoq.com/presentations/model-to-work-evans (part1) http://www.infoq.com/presentations/strategic-design-evans (part2)

Yes, you can model Vote as an aggregate unto itself. In the real world, often people vote for several things at once. The aggregate would then be called a Ballot instead of vote. You just have a special case where there is only one item to vote for at a time.

I can’t speak for MongoDB (perhaps someone else can) – but you would have a very easy time doing this in RavenDB with something like:

public class Match
{
    public string Id { get; set; }
    public string Name { get; set; } // or whatever
}

public class Vote
{
    public string Id { get; set; }
    public string MatchId { get; set; }
    public string UserId { get; set; }
    public bool YeaOrNay { get; set; } // or whatever
}

Then you would just build a map/reduce index over your votes to tally the results.