CQRS: How to implement a voting mechanism (many to many relationship)

5
votes

I'm rather new to CQRS and DDD and am wondering what would be the best way to implement a voting mechanism in the domain model.

On a product, a user can upvote/downvote. There are some domain rules regarding voting, f.e. you can only vote once, either down or up.

Both vote and product would be an aggregate root. Is this the best approach? It's recommended to keep the aggregates small. Adding the vote to the product aggregate root would overtime make it bloated.

The issue that I'm struggling with is deleting a vote when the vote is an aggregate root. You need to know which vote aggregate needs to be deleted. It's not possible in the command handler to retrieve the vote from the repository with the productId and userId. The aggregateId is stored as a single Guid in the database.

The command would contain these fields

  • UserId
  • ProductId

Some possible solutions that I have found:

  • Use a deterministic GUID based on the userId and productId
  • Votes are a list of aggregates on a product
  • Create a voteId and use that to delete the vote.
  • Store the aggregate as a string and use a combination of productId and userId

What would be the best approach?

1
domain-driven-designcqrsevent-sourcing
What do you mean by flagging as deleted? You need a compensating action, a new command with the same UserId and ProductId. – Daniel Alexandrov
There would be a new command with the same userId and productId. The command handler would then get the vote and set it as deleted(cancelled). – Valderann
Can you also explain it from business perspective, rather than purely technical? When can a vote be deleted? Is it a result of the user canceling their vote? Are there more cases when this is needed? – Daniel Alexandrov
The user would see two buttons(upvote, downvote). When the user presses the upvote button his vote is registered and the button is highlighted on the UI. When the user presses the upvote button again his vote is cancelled. – Valderann

1 Answers

6
votes

Using my limited understanding of your domain, I can conclude that there are two bounded contexts Catalog and Reviews. In this case, you could have a Product aggregate in the Catalog BC and one Product aggregate in the Reviews BC.

The Product aggregate from the Reviews BC would contain a list of all Vote entities for a particular product. A Vote entity would contain all the information needed in order to enforce the vote only once business invariant (like IP address, user ID etc). Both Product aggregates types (from the two BCs) would share the same ID - that's how you keep them synchronized, if you need (for example when a product is removed from the catalog it is marked as non-votable in the reviews BC).