How to have commands constrained on both ends with commanded

NobbZ

I’m playing with the thought to implement some same game using event sourcing to learn more about it.

Therefore I looked into the documentation of commanded and watched a talk about it. From the documentation and the talk it got pretty clear to me how I should model things that are constrained on one end like a bank withdrawal.

But how could one model transactions that are constrained on both ends?

In the context of the game the first thing came to my mind was a player dropping an item into a chest. The player needs to have the item in his inventory and it needs to fit in the receiving chest.

Currently, the only way I see after reading through commandeds documentation was to do it like this:

create a command that moves the item from the inventory to the chest.
check if the inventory contains the item in the execute function
create the event to move it into the chest
create the command that puts the item in the chest from the process manager
check if there is enough space in the chest and for this example it is not
Fire an event that rolls back the transaction
get that one back into the process manager
…

But is this atomic? Or could there be a race and the player picked already up another item and doesn’t have room left in his inventory anymore?

Are there possibilities I currently do not see because I have no experience in this field?

Is there a way to get my flow from above atomic? (or is it already?)

Thanks in advance!

1 comment

#event-sourcing #cqrs #commanded

2 1459 1

2019-01-16 22:05:46 UTC

Showing Posts 1 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

slashdotdash

Aggregate are used to enforce business invariants, but you also want to keep them as small as possible to allow concurrency of operations. Much like the trade-offs involved with deciding how to separate GenServer processes.

When you have inter-aggregate dependencies you have to use eventual consistency as you outlined, which can lead to race conditions. To alleviate this, a command will be validated up front by querying a read model to ensure that it is likely to succeed. In your example you would check the player’s inventory and receiving chest before attempting to drop the item. This limits failures to small race conditions which must be handled by executing a compensating command to undo the event that has already occured, but you’ve now determined is invalid - much like a reverse transaction in accounting. These operations are not atomic, but are possibly long-running sagas.

The reason for this approach is because limiting the size of aggregates and using eventual consistency allows infinite scaling (in theory at least) because you can distribute the aggregate process amongst any number of nodes and you are not relying on distributed transactions (which don’t scale). This is explained in more details in Pat Helland’s position papaer “Life beyond Distributed Transactions: an Apostate’s Opinion”.

Post #1

— All posts loaded —