Is it right to read the event sourcing when we want history?

Question

My application use CQRS architecture. Everything is performed through my aggregates, thus each user's action is saved as an event in my event source store.

Now, I need a new form which shows the history of every action performed in my application, so what should I do ?

1 - Read the event store ? How ?

2 - Publish an event in each of my domain handler like "SavedToHistory(User user, Action action, DateTime date) then in my event handlers, store it in my read data model ?

Answer 1

Since the whole idea of CQRS is to have separation of reading and writing, and of storage (reading vs writing again), I think the most consistent action you can take is to write denormalized history data to the Read database and read it from there rather than trying to read it from the Event Store.

This can be straightforward; you can write a general denormalizer that can write any new event in the Event Store to a denormalized version in the Read database, or you can have specialized denormalizers -- it depends on how you want to display history in your application.

Either way, write denormalized versions of your events to the Read DB so that your application will not need to know exactly how events are structured in the Event Store.

Answer 2

If you need to show full history for developers, then you can just replicate all events to a domain log (read model with aggregated list of all events that developers are allowed to see).

If you need to show history to the users, then showing deserialized events would not work that well. Instead you can have a read model that maps each event to an activity with some human readable description. That's what we do for facebook-like "what's new" feeds.

Same rules of managing read models apply in both cases - if you change rules for aggregating events or mapping them to the human-readable activities, then just drop the read model and rebuild it from the history completely.