I would argue that there is no such thing as "the business model". There may be a projected rolled up summary state... but that's only one possible view out of infinitely many. For example, one possible "business model" could be "customers who have changed their emails in the past month". You shouldn't favor any particular view as being the favored "business model"... unless you're doing snapshots, in which case everything goes out the window.

Basically, I vote for `SetCustomerEmail`.

Events have already happened. The idiomatic name would be `CustomerEmailSet` or perhaps just `EmailSet` or `EmailChanged`.

From my experience, definitely go with the second approach. Try to spend a lot of time initially defining the events with domain experts. Designing events that map well to the domain in the first place is the hardest, but also the most important criteria for success with event sourcing. Usually that means very specific event types. A simplified example from my career: an event EquityPurchased { Portfolio, Symbol, Quantity, Price } can be used when the customer says: "Our portfolio should calculate cost FIFO rather than average". Very specific events are also easier to version, because often something in the past version has been implicit. In the example the customer may say: "we are going to purchase some equities on the Oslo Stock Exchange, we didn't really care about currency and currency rates since we only bought US stocks before." So now we can make a new verison of EquityPurchased { Portfolio, Symbol, Quantity, Price, Currency = "USD", ExchRate = 1 }

If your events are well defined, you should be able to understand what happened by looking only on the event names. So, SetKeyValue is not good here: "what key? what does it mean?". CustomerEmailSet or CustomerEmailChanged clearly describes what happened with the customer.

> If your events are well defined

This is clearly the key to the whole picture.

Reading through this and other comments this morning, and I am starting to develop some concrete notions.

Seems like I simply need to build events for each unique type of fact that could exist in the domain. The verbosity of this seems extreme, but also makes a ton of sense.

The thought in my mind right now - If you combine event sourcing with a model in 6NF, the mapping should be trivial. Every fact table has its own series of events pertaining to it (Create/Update/Delete).

This also seems elegant - If your core data representation is inherently linear, do you care that you have this degree of normalization going on? You have to reconstruct some reasonable in-memory representation from the log anyways, so your live in-memory instance could be ~3NF while it ultimately transacts with a 6NF event log on disk. This also plays nicely with backwards compatibility and data migrations.

Start with very granular events. They can be aggregated later if needed, but the reverse isn't possible.

Isn't it the other way around? If you have an “AB” event, it's fairly trivial to go through the log and split it into “A then B”. If you have “A then C then B” for whatever reason and then realize that you need to aggregate “A” and “B”, that is much harder.