Commands, events and being idempotent? about cqrslite HOT 2 CLOSED

Hi. There are several ways to ensure idempotency with CQRSlite.

The first and perhaps simplest is to use the included versioning and optimistic concurrency to make sure the user works on the newest data. If two of the same commands where to be sent, things would throw out of order exception because the version was not as expected.

The second and more complicated way is to make sure all commands are idempotent. This would require a command like AddProduct to have a value like number of productsInCart instead of numberOfProducts added.

A third approach is to save the command stream and create a unique id when creating a command, and making sure that command is not already applied when you get it. This is not supported directly, so you have to extend the framework to find a good solution. If you do find a good solution to it, I'm interested in seeing how I could make this into the framework if it would make any sense.

I'm sure there are several other ways as well, but if you can try optimistic concurrency as it by far the simplest way. It's also built into CQRSlite, so it requires very little effort.

from cqrslite.

Hi, sorry didn't reply earlier here. To clarify you meant optimistic concurrency on command level all they way from the user's UI? That is a great safe guard to keep Aggregates valid and would be enough in most cases, I agree. I will see if I can get away with this.

In some situations it might be nice for the application to "know" if certain command succeeded (instead of seeing concurrency error), especially if user has little time to review and act on error (for example player registering scores in between points on watch: IWon, ILost commands). Things might get more complicated if multiple registrants might exists (if both players register scores for the same match).

from cqrslite.