How should concurrent request on the commandbus get handled? I have read through several articles and haven't found a conclusive approach.
One approach is that the commands are all added to a queue and then are executed one at a time. Another approach is some kind of "lock" that prevents two commands getting executed at the same time or another one allows multiple commands to get executed at once.
How should scenario's like this get solved:
1) first user deletes a product
2) second users add a comment to deleted product
How can we guarantee that if those two commands get run at the same time that the comment doesn't get added to a deleted product.
How should concurrent request on the commandbus get handled?
Review Race Conditions Don't Exist
A microsecond difference in timing shouldn’t make a difference to core business behaviors.
In a design where you are capturing decisions made somewhere else (the human decided to delete, the human decided to comment), you should be thinking through the fact that the humans are working concurrently, and may in fact be making conflicting decisions.
In other words, the problem needs resolution in your model, not in your plumbing.
Your persistent store should generally be understood to be enforcing a first writer wins policy. So you can have two concurrent processes running to update the store (or, to put it another way, you will often want to delegate the concurrency management to the persistent store, rather than trying to manage it in your stateless processes). The idea here being that the database changes much less frequently than the domain model, and therefore it is a lot easier to ensure there is only a single copy running at any given time.
Note: none of the above is particular to cqrs or event-sourcing; you would have the same race considerations if you had a single model and were replacing the durable copy of the current state.