Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance, scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions : https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing#:~:text=The%20Event%20Sourcing%20pattern%20defines,in%20an%20append%2Donly%20store.&text=The%20events%20are%20persisted%20in,current%20state%20of%20the%20data.
Context and problem
Most applications work with data, and the typical approach is for the application to maintain the current state of the data by updating it as users work with it.
CRUD (create, read, update, delete) approach has limitations in a domain-driven architecture and in a collaborative domain with many concurrent users : slowing down performance and responsiveness, update conflicts, additional auditing mechanism to add, etc.Solution
The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. The events are persisted in an event store that acts as the system of record (the authoritative data source) about the current state of the data.
Challenges