Event sourcing and persistence

If two aggregates are listening to the same event; then the event will be stored in an event store twice, once for each aggregate.

I would spell that differently. If two aggregates are listening to the same event, then representations of that event will appear in the history of each.

They won't be storing the same event, and the event that they store won't be the event that they are reacting to.

The aggregates will be storing events describing the changes to their own state, not the changes to state elsewhere in the domain that they are reacting to.

When you get that right, recreating the aggregates is easy - each aggregate loads its own history. There's no "double counting" to worry about, because each event in the history represents a change to an aggregate, so they are all different things.

Event storage

Event storage will depend on your application but it is a lot easier if you use a flexible storage for your events (so a NoSQL DB, JSON or XML). How you deal with updates will depend on several factors you need to take into account such as requirements for availability and timeframes for updates, amount of events, etc...

• Update your events when your application updates: as part of the deployment of a new application, update all your previous events to the new schema
• Version your events: have a version-id on your event. When an event is read from the database some piece of code knows how to 'upgrade' older events to the current structure. Like the first option, but basically 'on demand'
• Throw away your old events: when your application updates, make a snapshot of all entities and throw away (or archive) the old events.
• Never throw away old events: basically keep 'PurchaseOrder' forever. When you need another field, use a new event such as 'PurchaseOrderWithCouponCode'.

Saga's

A saga is basically a long-running event chopped up into pieces. This might be due to different reasons: it could be because you want to have an action that results in multiple events handled in parallel to avoid blocking with a transaction, because you need to coordinate several external systems, or because you need to coordinate with events that cross a bounded context. You need to persist them because of that reason: a saga can be started, launch a few events and at some non-deterministic point can have to resume by launching more events. Udi Dahan has a good introduction on this.

Message buses

There is a lot that can be said about buses. They abstract a large part of the storage of events for you and can handle more complicated scenario's, for example when you have multiple applications that need to work with the event store. For small applications you can write directly into the event store (and the code that would do that could be considered a bus...)

Data up to date

Short answer: you don't. Event sourcing works around this in several ways because you are 'eventually consistent'. In this example, you could simply display a message to the users that it might take up to ten minutes for deposits to show up...