At what granularity are events recorded in Event Sourcing?

Question

I'm growing my understanding of event sourcing. My understanding is that it provides a means of recording events as they happen so that given a common beginning state and an audit log of recorded events, the events can be replayed to achieve the same final state.

I know that sometimes events are triggered by other events. When I consider a system as a whole, I imagine that some events will be triggered externally by inputs from the user or another external source and that other events will be triggered and processed internally as side effects. I am calling the former originating events and the latter secondary events.

Originating events trigger a domino effect of secondary events. Since secondary events hinge directly on some originating event, should secondary events be recorded as part of the audit?

If you're aware of some source that discusses this in depth please cite.

Answer 1

I think you're mixing up event sourcing and command sourcing. There is crucial difference between them. With command sourcing, you register external commands, like user inputs. In event sourcing, you register effects of those commands, i.e. what you've called secondary events.

In practice, you should choose either command or event sourcing and stick to it, not combining these 2 approaches. As for which one to choose, it seems that industry consensus is skewing towards event sourcing. For example, in Akka, the Akka Persistence module is based on event sourcing.

Main idea behind choosing event sourcing over command sourcing is that former allows for idempotency. I.e. however many times you replay the effects of your operation, your system would end up in the same state, while with command sourcing you're trying to rely on a fact that same command executed at different time would produce the same effect, which is, needless to say, is incautious.

Answer 2

From a purely practical perspective, if you include events that are triggered by other events in your log, there are two consequences:

• If you need to replay the log, these events will be automatically triggered anyway, so you'll need a way of filtering them out
• If you later determine that the logic that generates some such events is incorrect, and therefore decide to rebuild your system by replaying all events to remove data corrupted by the bug, the log will still contain incorrect data

From this perspective, it seems clear that at the very least such events should be logged separately rather than together with externally sourced events.