#Event sourcing: choosing the source of truth

Event sourcing stores an aggregate's authoritative changes as an ordered event stream. Reconstructing state applies those events in sequence. State reconstruction must reproduce recorded decisions deterministically.

#A conceptual example

A hypothetical event-sourced Project could apply ProjectOpened, ProjectMemberAdded and ProjectMemberRemoved to reconstruct its membership. These are illustrative event names. The current Project implementation restores saved authoritative state.

Source: project.go

func RestoreProject(snapshot ProjectSnapshot) (*Project, error) {
	if err := snapshot.Validate(); err != nil {
		return nil, tactical.Corrupt(err.Error())
	}
	return &Project{state: snapshot.Copy()}, nil
}

Restoration validates a saved snapshot and raises no new facts. Reconstructing state must not trigger provider effects or reinterpret historical choices using today's external information.

#Snapshots and projections

An event-sourcing snapshot caches state at a known stream revision. The retained stream remains authoritative. In current-state persistence, the saved aggregate snapshot itself can be authoritative. Identify which meaning applies before designing replay or recovery.

A projection is a derived view. Rebuilding it requires a source that retains enough information and a recovery contract; an outbox may discard confirmed deliveries.

#Adoption needs a decision

The platform defaults to current-state persistence. Adopting event sourcing needs an explicit owner-scoped decision covering stream schemas, append concurrency, restoration, evolution, sensitive-data retention, migration and recovery tests.

The reference repository retains es in its name but also documents current-state persistence. Importing its educational material does not change this platform's storage policy. Read DDD.md and the architecture.

Next: Testing and exercises.

Adapted from the architecture reference, with Pharos examples.