An event that comes from event sourcing and command handlers should always portray actual change to the application state. When a command handler invalidate a command, it should not emit any events.
If you emit an event, this could confuse later projects, aggregators or other business logic. Since nothing actually happened, it’s not important for the state.
Some events might not be used in projects or aggregates
This does not mean that all events are necessary for some projection. If you have an event that actually does not matter for a later projection, doesn’t mean it shouldn’t be stored. If something truly happened, for example an event generated through an app, it should still be stored.
- [?] Does this warning fit, is this note correct. Think about events in the user history that does not make sense and are thus denied. Should the handler deny these events being like “Hey we cannot validate this command”, if so, that means that events are not saved and the business logic about which events to use are in the handlers, and thus could not change, you will drop some events?
Reference
Hoffman, Kevin. Real-World Event Sourcing: Distribute, Evolve, and Scale Your Elixir Applications. The Pragmatic Bookshelf, 2025. The Pragmatic Programmers.
Highlights or timestamps
Transclude of 1756163751-real-world-event-sourcing#^00004
Transclude of 1756163751-real-world-event-sourcing#^00005
Transclude of 1756163751-real-world-event-sourcing#^00008