Chapter 10. Event sourcing: a functional approach to persistence

为什么Persistence也可以保存Change而不只保存Current State

传统CRUD覆盖latest row，过去发生什么需另建audit。Event sourcing把domain facts append为immutable log，current state由ordered events fold得到。它天然适合functional transition/replay，但引入event schema permanence、projection lag、concurrency和operational complexity，不是通用升级。

先预测：append-only就等于event sourcing吗；replay同events必然同state吗；snapshot可随意覆盖吗；projection exactly-once是否由framework保证；event可按class rename直接迁移。答案都是否。

Thinking functionally about data storage

Functional view把storage reads当facts/snapshots，把writes当new facts/versions，而非远程mutable variables。Overwrite简单、query直接；immutable snapshots保留versions；events保留intent/history；hybrid用events+snapshots/projections平衡load和query。

overwrite: id -> latest row
snapshot:  (id, version) -> state
events:    (streamId, sequence) -> immutable fact

Event sourcing basics

核心分两functions：Fold(initial, events) -> state与Decide(state, command) -> events/error。Apply event应deterministic且无I/O；Decide只产生facts，不append。Shell load stream、fold、decide，再以expected version atomic append。

AccountState Fold(IEnumerable<AccountEvent> events) =>
    events.Aggregate(AccountState.Empty, Apply);
 
Either<Error, IEnumerable<AccountEvent>> Decide(
    AccountState state, Withdraw command) =>
    state.CanWithdraw(command.Amount)
        ? Right(new FundsWithdrawn(command.Id, command.Amount))
        : Left(Error.InsufficientFunds);

Architecture of an event-sourced system

Write path：load snapshot/tail、fold、decide、append(expectedVersion)。Conflict表示concurrent command基于stale state，需reload/redecide或返回conflict，不能盲重试旧events。Read path由projection消费events构建optimized views，通常eventually consistent。

Snapshot只是optimization，必须能验证stream/version和schema；删除events会改变source of truth。Projection consumer需checkpoint、idempotent update、duplicate/out-of-order policy与full rebuild。Outbox/subscription保证也要明确，不宣称神奇exactly-once。

var stream = await store.Load(streamId, token);
var state = Fold(stream.Events);
var pending = Decide(state, command);
await store.Append(streamId, stream.Version, pending.Right, token);

Operational replay gate

上线前把rebuild写成可重复runbook：在隔离read model从零消费golden streams，记录events/sec、lag、poison event、retry与checkpoint advance，完成后以golden queries和aggregate totals对比live projection。遇到unknown event不能跳过后继续宣称成功；应隔离stream、保留offset和原因，修复reader/upcaster后从安全checkpoint恢复。容量评估同时覆盖全量replay时长、双写切换窗口、磁盘峰值与回滚路径，确保“能重放”不是只在unit test成立。

Comparing different approaches to immutable storage

Event sourcing适合history本身有业务价值、复杂state transition需audit/replay、多projections受益的domain。Versioned snapshots适合point-in-time但不需intent；append audit+CRUD适合记录变更者；temporal DB提供system-time query。按requirements、team ops和schema evolution选择。

Event schema一旦发布就是长期contract。Prefer stable semantic events；rename/internal refactor不改wire name。需要upcaster/new event version时保留old reader与golden streams。

本章回顾：Pure Fold不等于简单Operations

1. Event sourcing保存domain facts，state由ordered deterministic fold重建。
2. Decide产生events，shell以expected version append，I/O不进入Apply。
3. Projection、snapshot是derived optimization，需要checkpoint、idempotency和rebuild。
4. Event schema是长期contract，internal rename不能破坏history。
5. CRUD/audit/snapshot/events各有tradeoff，按domain history价值选择。

术语表

原版目录概念补充核对

以下条目补齐官方目录中容易被示例主线掩盖的概念。它们不重复罗列目录，而是明确每项概念的机制、适用边界和验收证据。

Architecture of an event-sourced system：机制、边界与证据

Chapter 10. Event sourcing: a functional approach to persistence中的Architecture of an event-sourced system应写成可组合的输入—输出契约，并把环境读取、状态改变与失败显式放在边界。用确定输入运行正常、空值和失败样本，同时记录返回值与副作用轨迹，证明结论不依赖隐藏状态。