Event sourcing saves all data-changes in a chronological order as domain events. These events can be replayed to ‘hydrate’ the current state of the data.
Sometimes these hydrated events or projections will be persisted in the database to make this process more performant.
This pattern fills the need to save all possible actions, revert back to a state and know the full path an object went through.
Event driven architecture is not the same
These two concepts should not be confused with eachother. Read more about event-driven architecture.
Reference
Wierik, M. te. (2022, November 14). Event sourcing versus event-driven architecture. Geek Culture. https://medium.com/geekculture/event-sourcing-versus-event-driven-architecture-753aa5a5d0f6
Highlights or timestamps
Event Sourcing Versus Event-Driven Architecture
But what if it is desired to track as well the complete series of actions taken of that data? The event sourcing pattern fills in this need. With event sourcing, data changes are getting saved in domain events. These events are held in the chronological order of occurrence. These events can be replayed to get to the current state of the data.
— ^e90fbd from Event Sourcing Versus Event-Driven Architecture