Return to Question

I'm growing my understanding of event sourcing. As I understand event sourcing 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. 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.

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.

I'm growing my understanding of event sourcing. As I understand event sourcing 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 are will be triggered and processed internally. 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.

I'm growing my understanding of event sourcing. As I understand event sourcing 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. 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.

I'm growing my understanding of event sourcing. As I understand event sourcing 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 are will be triggered and processed internally. I am calling the former originating events and the latter secondary events. Originating events trigger a domino effect of secondary events.

Considering that one triggers the other is it normally recommended that secondary events also be recorded?

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

I'm growing my understanding of event sourcing. As I understand event sourcing 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 are will be triggered and processed internally. 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.