Event Sourcing: How to model relationship between different events?

Question

I am new to Event Sourcing and I have encountered an example which I am not quite sure the pros and cons of different approaches.

Let's say this is a bank example, I have three entities Account, Deposit and Transfer.

My idea is, when a use deposits, command bank.deposit will create two events: deposit.created and account.deposited. Can I or should I include the deposit.created event uuid in account.deposited as a reference?

Taking to the next step, if later the bank has a transfer feature, should I made a separate event account.transfer_received or I should created a more general event account.credited to be used by both deposit and transfer?

Thanks in advance.

Answer 1

A good article to review is Nobody Needs Reliable Messaging. One key observation is that you often need identifiers at the domain level.

For instance, when I look at my bank account, and see that the account history includes a specific deposit, there is an identifier for the deposit that is reported in the view.

If you imagine it from an event sourced perspective, before the deposit the balance was X, and the history did not include deposit 12345; after processing the deposit, the balance was X+Y and deposit 12345 was in the account history.

(This means, among other things, that if a second copy of deposit 12345 were to appear, the domain model would know to ignore it even if the identifier for the event were different).

Now, there are reasons that you might want to keep various message ids around. See Hohpe's work on Enterprise Integration Patterns; in particular Correlation Identifier.

should I made a separate event

Usually. "Make the implicit, explicit". The fact that two events happen to have similar representations is not a reason to blur them when the ubiquitous language distinguishes the two.

It's somewhat analogous, in motivation, to providing a task based ui or eschewing the user of generic repositories.