活動來源：基本知識

什麼是Event Sourcing

Event Sourcing （ES）是將域對象的狀態存儲為「當前字符串」而不是描述發生的任何事物的不可變事件日誌的一種方式。聚合的當前狀態是通過其事件的卷積（復制）獲得的，並且任何要讀取的視圖都構造為該日誌頂部的投影。

• 故事是「真理的主要來源」，狀態是故事的投影。
• 任何狀態都可以重新復制、驗證和解釋（審核）。
• 添加新的視圖和分析不需要遷移舊的「快照」-只需輸掉事件即可。

基本術語

聚合是具有明確不變量（秩序，支付，用戶平衡）的一致性域單位。

該事件是過去發生的不變事實（'payment。authorized`, `order.shipped`).

Event Store是一個append-only日誌，在集合中提供事件順序。
聚合版本是應用的最後一個事件的編號（用於優化順序）。
Snapshot是一種周期性的狀態鑄件，用於加速卷積。
投影（讀取模型）是用於閱讀/搜索/報告（通常是異步的）的實例化視圖。

如何工作（命令流→事件→投影）

1.客戶端發送命令（「CapturePayment」，「PlaceOrder」）。
2.聚合物驗證不變量，如果所有，則產生事件。
3.事件通過版本驗證（optimistic concurrency）原子添加到Event Store中。
4.投影處理器訂閱事件流並更新讀取模型。
5.加載以下命令的單元時，狀態會恢復：snapshot（如果有）→ snapshot後的事件。

活動設計

強制屬性（內核）

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"aggregate_type": "Payment",
"aggregate_id": "pay_123",
"aggregate_version": 5,
"occurred_at": "2025-10-31T10:42:03Z",
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"meta": { "trace_id": "t-abc", "actor": "user_42" }
}

• 命名："域。action.v{major}`.
• 可加性：新字段-可選，不改變舊字段的含義。
• 極簡主義：只有事實，不重復容易恢復的數據。

合同和計劃

捕獲電路（Avro/JSON Schema/Protobuf）並檢查CI上的兼容性。
對於「中斷」更改，是事件的新主要版本，並且在遷移期間並行發布「v1」/「v2」。

競爭性訪問： 優化兼容

規則：只有在'expected_version==current_version'時才能記錄新事件。

pseudo load: snapshot(state, version), then apply events > version new_events = aggregate. handle(command)
append_to_store(aggregate_id, expected_version=current_version, events=new_events)
//if someone has already written an event between load and append, the operation is rejected -> retray with reload

因此，我們保證了不分布式事務的不變量的完整性。

Snapshots（卷積加速）

每N事件或計時器進行一次狙擊。

Храните `snapshot_state`, `aggregate_id`, `version`, `created_at`.

在snapshot之後總是檢查和追趕事件（不要只相信演員）。
移除snapshots，以便可以將其從日誌中重新放置（不要存儲「魔術」字段）。

投影和CQRS

• Write模型=聚合+活動商店。
• 閱讀模型=事件更新的投影（Redis卡，OpenSearch用於搜索，ClickHouse/OLAP用於報告）。
• 投影是偶然的：相同的「event_id」的重新處理不會改變結果。

電路的演變和互操作性

Additive-first：添加字段；不要改變類型/語義。
對於復雜的更改：發布新的事件類型並編寫投影遷移器。
支持過渡期的雙重錄音（「v1」+「v2」），並在所有投影準備就緒時拍攝「v1」。

安全，PII和「遺忘權」

• 最小化事件中的PII（標識符而不是數據,部件在受保護的側面）。
• 加密擦除：加密字段,並在請求刪除時銷毀密鑰（事件仍然存在,但數據不可用）。
• 修訂事件：'user。piiredacted.v1'替換投影中的敏感字段（歷史記錄保留了編輯事實）。
• 轉義策略：對於某些域,可以將某些事件存檔到WORM存儲中。

性能和擴展

分黨：分組內的順序很重要-通過「aggregate_id」分黨。
冷啟動：snapshots+周期性的「密封」卷積。
Batch-append：將事件分組為一個事務。
用於投影處理器的背景和DLQ；測量差值（消息的時間和數量）。
事件商店索引：通過「（aggregate_type，aggregate_id）」和時間快速訪問。

測試

集合的規範測試：「命令→預期事件」腳本。
Projection tests：提交事件流並檢查實例化狀態/索引。
Replayability tests：從頭開始重新包裝展位上的投影-確保總數匹配。
Chaos/Latency：註入延遲和雙擊,檢查等效性。

域示例

1）付款

事件： '支付。initiated`, `payment.authorized`, `payment.captured`, `payment.refunded`.

不變式：沒有「授權」就無法進行「捕獲」；金額為非負數；貨幣不變。
投影：「支付卡」（KV），交易搜索（OpenSearch），報告（OLAP）。

2）訂單（電子商務）

事件： 'order。placed`, `order.paid`, `order.packed`, `order.shipped`, `order.delivered`.

不變量：狀態圖中的狀態過渡；在「shipped」之前可以取消。
投影：用戶訂單列表，按狀態排列的SLA-dashbords。

3）資產負債表（財務/iGaming）

事件： 'balance。deposited`, `balance.debited`, `balance.credited`, `balance.adjusted`.

剛性不變性：平衡不會消失<0；根據「operation_id」命令是相等的。
關鍵操作直接從單元（嚴格的一致性）讀取，UI從投影（事件）讀取。

活動商店的類型結構（DB變體）

events

`event_id (PK)`, `aggregate_type`, `aggregate_id`, `version`, `occurred_at`, `event_type`, `payload`, `meta`

索引：「（aggregate_type，aggregate_id，版本）」。

snapshots

`aggregate_type`, `aggregate_id`, `version`, `state`, `created_at`

索引：「（aggregate_type，aggregate_id）」。

consumers_offsets

「consumer_id」，「event_id」/「position」，「updated_at」（用於投影和轉發）。

常見問題（FAQ）

是否必須在任何地方使用ES？
沒有。當審計，復雜的不變性，可重復性和不同的數據表示很重要時，ES很有用。對於簡單的CRUD，這是多余的。

如何處理「最新狀態」查詢?

要麼從投影中閱讀（快速，事件），要麼從集合中閱讀（更貴，但嚴格）。關鍵操作通常使用第二種方法。

需要一個Kafka/流經紀人嗎?

事件商店是真理的來源；經紀人方便將事件分發給投影儀和外部系統。

如何處理「遺忘權」？
最小化PII，加密敏感字段並在投影中應用加密擦除/修訂。

如何遷移舊數據?

編寫回顧性事件生成腳本（「re-highstori」）或從「狀態不變」開始,僅發布新更改的事件。

反模式

Event Sourcing「按習慣」：使系統復雜化，沒有域收益。
Fat events：帶有PII和雙打的腫脹的薪水-制動器和合規性問題。
缺乏優化順應性：賽車中不變量的喪失。
不可制作的投影：沒有反射/snapshot →手持小玩意。
原始CDC作為域事件：DB方案泄漏和剛性連通性。
融合內部和整合事件：向外發布穩定的「展示櫃」。

生產的支票清單

• 定義聚合、不變量和事件（名稱、版本、模式）。
• Event Store在聚合和優化匹配中提供順序。
• 包括snapshots和重新構建它們的計劃。
• 投影是冪等的，有DLQ和滯後度量。
• 方案在CI上驗證，版本策略-記錄在案。
• PII最小化，字段加密，存在「遺忘」策略。
• 在展臺上檢查投影的倒置；有一個災難恢復計劃。
• Dashbords：上遊速度，投影時差，應用錯誤，後退比例。

底線

Event Sourcing使系統的歷史成為一流的人工制品：我們捕捉事實，從中復制狀態並自由構建任何表示形式。這提供了審計，對變化的抵抗力和分析靈活性-受制於計劃，競爭控制和對敏感數據的熟練處理。