Event Sourcing – Why It’s Considered an Anti-Pattern

Number 1 jumps out as an elegant way to do this. Can you elaborate on why Event Sourcing would result in the same emails being sent multiple times ? ES systems normally have ways to distinguish between when an event is raised for the first time and when it is reapplied later. See line 90 of this code from one of Greg Young's repos.

2 . is also an option if you consider the command handler as an Application Service. Notification sending may be viewed as application-dependent -- if the applicative context is a UI-less batch program editing thousands of posts, maybe you don't want emails to be sent.

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...