Convention over configuration to convert events to in memory model

[wli3]

So Update method in the Event can be shrunk down a lot.

For example, if there is event UserAddressChanged {"NewAddress": "650 S R.L. Thornton Fwy, Dallas"}

the Update method in UserAddressChange would look like this bankAccount.Address = @event.NewAddress;

Actually this kind of override or add is majority of the Update logic. This behavior should be the default without extra code. Say, if the field is started with New, then override or add corresponding field of in memory object.

This sounds hacky in the beginning, however, Event should be align with .Domain logic, so in this case, highly couple is encouraged. In extreme case, Update would be completely redundant, if your event modeling is perfect. However, a basic override convention is a good enough at this point.

BankAccountCreated --- new BankAccount(); Created is the convention of create new object, and the string before Created is the class name SavingDeposited { "AddSaving": 30} --- bankAccount.Saving += 30; Add is the method of how to update, Saving is the field name

[jonsequitur]

This kind of convention is likely only partly applicable in any given domain model, allowing some fields to be set by convention and others still needing to be updated "manually".

For example, this would work for a known set of verbs, typically CRUD-y verbs such as Updated, Changed, Created, Deleted. Ideally though you want your domain language to be more specific than that. Instead of UserAddressChanged, I look for event names that capture why the address changed. Did the user move? Was additional information added to the address by customer service after a failed delivery attempt?

So this kind of convention is deliberately left out of scope because it's going to vary widely with how people model different domains.