Yesterday you developed most of the design for funds-transfer-component but left one question hanging. What was missing from the design?
As the design ended yesterday, when funds-transfer-component recycles the Transfer command, it’ll directly write a Withdraw to account-component. account-component expects its callers to send a withdrawal_id, and presumably, funds-transfer-component would have to generate that each time it sends a Withdraw.
Each time. Meaning, it’ll generate new identifiers for the same transfer. You thought you were moving 5 clams, but because of recycling, you’re moving 5 clams for each recycling.
Let’s find a better strategy for our job security.
Taking note of the identifiers
The hidden step reveals itself, the Initiated event. The full flow with it:
When writing Initiated, we copy all the fields from Transfer, adding to it processedTime, the point in time when it processed the message. We also generate withdrawalId and depositId, identifiers that we’ll use to send our clam-moving commands to account-component, and attach those to Initiated as well.
When handling the Initiated event, we then use those previously-generated IDs to send commands to account-component. Even when we recycle Initiated, we’ll pick up the same identifiers each time. Because account-component is idempotent, we’ll avoid duplicate clam movement.
Next steps
For our next step, we have to figure out how funds-transfer-component will know when the account transactions complete. From the model, you can see it has something to do with account-component’s Withdrawn and Deposit events, but how will we use those, and how will we know if a particular event from account-component is one that we care about because it’s part of one of our transfers?
Give it a shot, and see if you can think of a solution.
