search

gautema / CQRSlite

A lightweight framework to help creating CQRS and Eventsourcing applications in C#
Other
1.1k stars 266 forks source link

Commands, events and being idempotent? #96

Closed HippyRock closed 4 years ago

HippyRock commented 4 years ago

This is more like question not an issue. Anyway, are there any ways to keep my commands idempotent? For example as described here:

For example, a Cart aggregate root might have a method addProduct(), which returns a CartContentsChanged event. If you call addProduct() the first time, it adds a line item to the cart with a quantity of 1. If you call it a second time, it adds increases the line item quantity to 2.

If there is no out-of-box solution for CQRSlite, then any ideas how it can be extended to achieve that.

Thanks!

gautema commented 4 years ago

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.

HippyRock commented 4 years ago

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).