The event store should not allow modifying or deleting the events2 since it’s append- only storage. To support implementation of the event sourcing pattern, at a minimum the event store has to support the following functionality: fetch all events belonging to a specific business entity and append the events. For example:

interface IEventStore

{

IEnumerable<Event> Fetch(Guid instanceId);

void Append(Guid instanceId, Event[] newEvents, int expectedVersion);

}

The expectedVersion argument in the Append method is needed to implement opti‐ mistic concurrency management: when you append new events, you also specify the version of the entity on which you are basing your decisions. If it’s stale, that is, new events were added after the expected version, the event store should raise a concur‐ rency exception.

2 Except for exceptional cases, such as data migration.

In most systems, additional endpoints are needed for implementing the CQRS pat‐ tern, as we will discuss in the next chapter.

In essence, the event sourcing pattern is nothing new. The financial industry uses events to represent changes in a ledger. A ledger is an append-only log that documents transactions. A current state (e.g., account balance) can always be deduced by “projecting” the ledger’s records.