DDD\CQRS\Event Sourcing and request historical data

4
votes

I read the book Patterns, Principles, and Practices of Domain-Driven Design I really liked the approach to use DDD together with CQRS and Event Sourcing. But I have one question. How to use DDD\CQRS\Event Sourcing can I get historical data? For example. I would like to write a service that provides weather information. The client can request from service historical data. For example, Snapshot of weather in London in the last year, with the step one hour for drawing graphics and client can subscribe to real-time data for updating already constructed graphics. Question. How do I use DDD\CQRS\ES approach to send historical data to the client who has requested them. I can not send the event directly to the message bus, because the service may have several clients and not all clients need these data.

Update.

I would like to show in the client something like this. enter image description here

2
c#eventsdomain-driven-designcqrs
that's the point of publishing events vs sending commands. only those interested can listen. you could also look into providing a REST API where you can let the clients pick and pull which events they care about. - Marco

2 Answers

1
votes

If I understand your question correctly, you want to request the data. Within CQRS there is a seperation between retrieving the data (through Queries) and writing/adjusting the data (through Commands). Everytime you whish to change the data (through a Command), you fire an event and save it to your EventStore. You can use a Projection to make a presentation you want for the data, you can even save this in another database.

I'll try to eleborate on your example:

  • every hour an event is fired to the EventStore with the current weather conditions and the datetime of the measurement (this could be an solution for importing old data)
  • the eventstore, fires an projection (with your own wanted presentation), that is saved to another database (which you can easily query)
  • this is database is accessible through queries.

It might be possible to leave the other database out, but it could be an solution to present queries quicker, because this database (with its replicas) is only responsible for reads within your app, while your eventstore does all the heavy lifting (writes).

0
votes

Usually to get a historical view you would load aggregate with only the events up to the time period you are interested in. This would give you you the snapshot view at that time.

How are you getting the current view of weather? Loading all weather events for all time for the requested location?

If all of the graph drawing etc is being done by the clients and you are simply delivering the events, then you can simply allow clients to request part of an event stream through your api. You would not be 'publishing' these events again to all clients as these have already happened. Clients would either be calling your api to get notification of 'new' events or would be getting 'historical' events or would be getting events since a time followed by new events.

At least that is my understanding of how it would work.