兩種載體的語意對照

「錯過的代價」那一列是實務上最好用的分辨器。畫面剛好沒訂閱時漏掉一次書單更新，下一次更新全額補償——狀態流語意。稽核系統漏掉一筆「書籍已刪除」，那筆事實永遠消失——事件語意。同一個資料變更常常兩種消費者都有：刪一本書，審計要那個事實（event）、清單畫面要新的書單（狀態流）——這不是二選一，是兩條正交的出口。

事件命名的過去式約定本身就是語意宣告（展開見 Domain Event 命名的過去式）：過去式承諾「這是已發生的事實」。當事實開始被當成「請刷新」的訊號消費，這個承諾就被消費端改寫了——下面的案例走的正是這條路。

案例：一條斜坡的三步

一個書庫管理 App 的統計頁需要在資料變更後刷新。repository 是純 pull 介面、沒有狀態流出口；但專案有現成的 EventBus、也有數十個 domain event 發布點。「用既有的事件當刷新訊號」看起來是零成本的選擇——這是斜坡的入口。

第一步：橋接。用 StreamProvider 包 EventBus、ViewModel 監聽事件流、任何事件進來就重新查詢統計。上線有效：匯入完成事件、同步事件都正確觸發刷新。

第二步：斷鏈暴露枚舉本質。搜尋加書與掃描加書路徑不刷新——盤點發現這兩條寫入路徑從未發布任何 domain event。事件的發布時機由業務語意決定（「匯入完成」值得記錄；「使用者加了一本書」當時沒有下游流程需要它），而刷新的涵蓋面要求「每條寫入路徑都有事件」。兩個需求的形狀本質不同：事件的涵蓋面是業務事實的集合、狀態流的涵蓋面是寫入操作的集合。用前者服務後者，缺的部分只能靠枚舉補——為了刷新而補發事件。

第三步：語意綁架成形。補發事件的修法一旦開始，事件系統的演進被刷新需求綁住：新增寫入路徑的檢查清單多了「記得發事件、否則某頁不刷新」；想移除一個再無業務消費者的事件、要先確認沒有畫面靠它刷新；監聽端則因為「不知道哪些事件代表資料變了」而全事件監聽、任何無關事件都觸發一次重新查詢。每一步都合理、加總起來是兩個系統互相持有對方的隱含契約。

這個專案在第三步前停下，把問題拉回載體選擇：統計頁的問題是「現在是什麼」（當前書庫統計）、不是「發生了什麼」。正確載體是狀態流——repository 補 Stream<List<Book>> 觀測出口、畫面 ref.watch 訂閱，涵蓋面天然等於寫入操作的集合（每個寫入方法尾端 emit），沒有「記得發」這個動作。演進全記錄在 ref.watch 觀察的是 provider 圖、不是資料庫、分層落地在 觀測出口的職責三分。

正交性：加了狀態流、事件一個不動

載體分清楚之後最有力的驗證是改動面：狀態流落地時，既有事件發布點零改動。事件仍然記錄業務事實、服務審計與跨 domain 通知；狀態流負責「資料變了」的觀測。兩者正交、互不取代：

「結構性涵蓋」與「逐事實設計」的差異就是兩種載體不可互換的原因。狀態流的 emit 掛在寫入方法上、新路徑必然經過、涵蓋不靠任何人記得；事件的發布點是設計決策、每個事件都該有業務理由——被迫「為涵蓋而發」的事件是沒有事實語意的雜訊，反過來稀釋整個事件系統的可信度（事件多到沒人知道哪些重要時，跨 domain 通訊的成本問題見 用事件做同步查詢等於手工重建 RPC——同一族的載體誤用、方向相反：那篇是拿事件做請求回應、本篇是拿事件做狀態通知）。

判讀訊號

斜坡的每一步都有可觀察的訊號，出現任何一個就回到載體判準重新選：

第四個訊號值得單獨說明：事實的 payload 是「這件事的內容」（哪本書、什麼時間），快照的 payload 是「現在的全貌」。事件開始攜帶全量狀態、通常是因為消費者拿到事件後只想要最新值——那正是狀態流一次 emit 就給完的東西。這個訊號有適用邊界：它假設消費者與事件來源在同一進程、同一信任邊界內。跨服務情境下，刻意讓事件攜帶足量當前狀態是 event-carried state transfer 這個正當設計——目的是讓下游服務不必回頭查詢來源、避免同步耦合，那時「payload 帶全量狀態」是設計選擇、不是載體錯位。本案是單一 App、同進程，沒有跨服務查詢成本，才適用「該補的是狀態流」的判讀。

四個訊號量的不是同一種東西。訊號一、二、四直接檢驗「消費者現在問的是哪種問題」；訊號三（移除事件前要先查有沒有畫面靠它刷新）量的是選錯載體之後累積的耦合成本——它是後果訊號（lagging indicator），等綁架已經長出來才觀察得到。把它跟前三個並列，是因為它同樣觸發「回到載體判準」，但它遲到、指向的是已經發生的綁架而非正在發生的誤用。

以上訊號都指向同一個方向：把事件當成狀態流用。反方向的誤用同樣存在、訊號相反——消費者需要的是逐筆離散事實（每一次庫存調整、每一筆退款），系統卻只給得到最新快照。症狀是稽核回頭找「中間發生過什麼」時只有結果沒有過程、或下游流程因為錯過中間狀態而少觸發。此時該補的是 event、而不是把狀態流的快照硬拆成假事件。兩個方向共用同一條判準：問「發生了什麼」給事件、問「現在是什麼」給狀態流——判準對稱，誤用可以往兩邊倒。

邊界

本章的判準處理「資料變更通知」這一種需求的載體選擇。事件對另外兩種離散訊息（命令、查詢）的責任結構分界在 domain event 與命令、查詢；狀態流的實作選型（broadcast、初始值、生命週期）在 StreamProvider 包 repository watch stream。另外，CQRS 階梯頂端「以事件同步讀模型」是事件的合法消費——那裡的消費者問的確實是「發生了什麼」（用事實重建投影），與把事件當刷新鈴聲不同層；階梯全貌見 讀模型的升級判準。這也標出本章「兩者正交」論述的架構前提：狀態存在獨立儲存、事件只是旁支通知。event-sourced 架構把這個前提拿掉——狀態流成為事件的投影、由同一條事件流重建，兩條管線不再獨立，正交性讓位給「讀模型由事件同步」的第四階語意。

下一步

決定用狀態流之後，先讀 觀測出口的職責三分 搞清楚契約、機制、組裝分別放哪一層，再進 ref.watch 觀察的是 provider 圖、不是資料庫 看案例從導航補償到狀態流的完整演進。事件命名的過去式約定（為什麼叫 BookAdded 而不是 AddBook）展開在 Domain Event 命名的過去式。讀側若走到階梯高處、要用事件同步投影的代價評估，見 讀模型的升級判準。

三種訊息的責任結構

「失敗語意」那一列是三者最深的差異。命令的處理者可以說不：庫存不足、狀態不允許、驗證失敗——失敗是命令語意的一部分、發送端要準備收到拒絕。事件沒有這個位置：BookImported 發出時匯入已經完成，訂閱者遲到、出錯、根本不存在，都改變不了這個事實——訂閱者的失敗是訂閱者自己的問題、不回流到發布端。查詢的失敗又是另一種：查不到、等太久、通道斷了，每一種都要有回應路徑、因為呼叫端停在那裡等。

責任結構決定演進自由度：事件的發布端不知道誰在聽、加訂閱者不改發布端；命令的發送端跟處理者是一對一契約、換處理者要重新對齊語意；查詢的兩端綁最緊、簽名一動兩邊都動。

命名是責任結構的第一道宣告

事件用過去式命名、是把責任結構烙在讀者第一眼接觸的地方：

1class BookImported extends DomainEvent { }   // 事實：已發生、不可否認
2class ImportBook extends DomainEvent { }     // 命令的形狀——「去匯入這本書」

ImportBook 這個名字的問題超出風格：動詞開頭是命令的形狀，訂閱者會用命令的心智模型寫處理邏輯——以為自己能影響流程、以為失敗會被重試。過去式的 Imported 宣告木已成舟，訂閱者知道自己只能對事實做反應。一個書籍管理 App 的命名規範修正記錄了這條分界的完整推導、以及過去式字尾自動檢查的脆弱性（不規則動詞全數漏接——偵測可以機械化、判定要看語意）：事件命名的過去式是語意類別、不是風格。

查詢裝進事件通道：手工重建 RPC

第二種錯位的方向相反：把對話裝進通知通道。同一個 App 的借閱功能要在建立借閱記錄前查書籍資訊，直接呼叫另一個 domain 的 repository 違反依賴方向；修正方案選了事件驅動的 request/response——BookInfoRequested 發出、BookInfoProvided 回應。耦合確實解掉了，但設計規格裡跟著出現的每一項機制、都是同步呼叫免費附贈的東西：

這張表的形狀有個名字：用事件通道手工重建 RPC。事件的天然語意是通知——fire and forget、任意多訂閱者、無所謂回應；一問一答的對話硬放上通知通道，RPC 的基礎設施就得自己蓋一遍、而且每個跨 domain 查詢點都要再蓋一遍。名字先洩漏了錯位：BookInfoRequested 的「Requested」記錄的是「有人想要」這個請求、不是業務世界發生的事實——事件命名的過去式測試在這裡當了偵測器，兩條判準在名字上交會。

事件真正買到、而更便宜的工具給不了的能力有兩樣：時間解耦（發布者不等回應、雙方可以不同時在線）與基數解耦（一個事件任意多訂閱者）。這個案例的查詢是同進程、一對一、呼叫端必須等到答案——三個特徵全部用不到事件的能力。解依賴方向有便宜一個量級的工具：消費端宣告自己需要的 port、對方提供實作、組裝層接線，依賴倒置同樣成立、呼叫還是一次普通的 await。完整比價（含 Port 版的介面設計）見 用事件做同步查詢等於手工重建 RPC。

判準收斂成兩行：

• 要解的是依賴方向（同進程、一對一、要等答案）→ 消費端 port、付一張介面的價
• 要解的是時間、部署或基數（跨進程、離線佇列、多方反應）→ 事件、correlation 與 timeout 是這個量級的合理成本

判讀訊號

前三個訊號的修法方向一致：回到責任結構重新分類——是意圖就改命令通道（或直接呼叫 use case）、是對話就改查詢（消費端 port）、確認是事實才留在事件。第四個訊號防反向矯枉：把所有跨 domain 通訊都收回同步呼叫、會把真正需要時間與基數解耦的場景也一起收掉。

邊界

本章處理事件與命令、查詢的訊息類型分界——三者都是離散訊息、差在責任結構。事件與 狀態流（連續觀測）的分界是另一個維度：那裡兩邊都不要求執行、差在「發生了什麼」與「現在是什麼」的時間語意，見 domain event 與狀態流。事件跨服務攜帶全量狀態的 event-carried state transfer 是分散式情境的正當設計、其適用邊界也在該章。

下一步

事件的另一條分界（對狀態流）在 domain event 與狀態流——兩章合起來把 domain event 對三個鄰居（命令、查詢、狀態流）的邊界畫完。兩個 case 的完整記錄：事件命名的過去式、用事件做同步查詢等於手工重建 RPC；port 解依賴的實戰在 mock 55 個方法只用 5 個。

概念位置

domain event 是 aggregate root 執行業務操作後的副產品——aggregate 保證一致性、event 把「剛才發生的事」通知外界。event 的消費者是跨 domain 流程、審計、通知等「需要知道發生了什麼」的角色。它跟 read model 在 CQRS 第四階交會：讀模型由事件同步時，消費者問的確實是「發生了什麼」（用事實重建投影），這是 event 的合法消費。

可觀察訊號

event 被借用成 UI 刷新訊號時會出現四個判讀訊號：為了讓某頁刷新而補發事件、監聽端掛全事件過濾器、移除事件前要查有沒有畫面靠它刷新、event payload 開始塞當前完整狀態。任一出現，回到載體判準重新選——消費者問「現在是什麼」時，正確載體是狀態流。

設計責任

domain event 記錄業務事實、服務審計與跨 domain 通訊。event 的發布時機由業務語意決定（「這件事值得記錄、有下游需要它」），涵蓋面是業務事實的集合——跟狀態流的涵蓋面（寫入操作的集合，結構性涵蓋）正交。載體選用判準、案例演進與判讀訊號展開在 domain event 與狀態流；事件對命令與查詢的責任結構分界展開在 domain event 與命令、查詢。命名的過去式約定展開在 Domain Event 命名的過去式。

概念位置

單一 bounded context 內的架構判準，跨過邊界不必然照搬。讀模型升級的四階梯（消費端投影 → 抽讀 port → 專用投影 → 事件同步的獨立儲存）假設操作發生在單一 bounded context 內；報表服務訂閱多個 domain 的事件建置共享視圖，是跨 bounded context 的讀模型，這時引入的關注點——跨服務事件契約穩定性、schema 演進、跨信任邊界的最終一致性——不是「多買一種能力」能概括，完整推導見 讀模型的升級判準。這類跨邊界溝通的常見載體是 domain event，其中攜帶足量狀態給下游的作法見 event-carried state transfer。

可觀察訊號

一個判準句在單一服務內成立、換到跨服務場景就開始要補額外的機制（契約版本、schema 遷移、補償流程），是踩到 bounded context 邊界的訊號——原本的判準沒有錯，是它的適用範圍被劃在邊界內，邊界外要重新論證。

設計責任

bounded context 的設計責任是替模型畫出「在哪裡可以直接假設一致」的邊界，邊界外的互動改走顯式的契約與轉換，不能沿用邊界內的內部語意。這條邊界也是判斷同一套架構結論能不能套用的分界——邊界內成立的推導，邊界外要重新論證，不是預設繼續有效。

概念位置

EventBus 是 domain event 的傳輸機制、不是事件本身：event 是「發生了什麼」的事實記錄，EventBus 是讓這個事實從發布端跑到訂閱端的管道。EventBus 只解決「怎麼送達」，送達之後訂閱端該把事件當事實通知還是當變更信號來用，是另一個判準，見 domain event 與狀態流。

可觀察訊號

訂閱端掛上「監聽全部事件、任何事件進來就重新查詢」這種全事件過濾器，是把 EventBus 兼職成變更通知管道的訊號——這條路徑上線初期有效，但涵蓋面等於「有沒有人記得發事件」，跟寫入操作的集合不天然相等，多個視圖各自解「怎麼知道資料變了」時容易補出交叉且不完整的補償策略。

設計責任

EventBus 只承擔「發布／訂閱」這一層機制、不承擔涵蓋保證——涵蓋是靠每個寫入路徑記得呼叫 publish 換來的，EventBus 本身不驗證有沒有漏發。需要涵蓋面天然等於寫入操作集合的場景，正確載體是 observation outlet 的狀態流、不是把 EventBus 的監聽範圍擴大，完整案例見 觀測出口的職責三分。

概念位置

這個設計只在跨服務、跨信任邊界的情境下成立。同進程情境下，事件開始攜帶全量狀態通常是載體錯位的訊號——消費者真正要問的是「現在是什麼」，正確載體是 state stream 而非塞胖的事件；跨服務時「回頭查詢來源」本身有同步耦合的成本，event-carried state transfer 用胖 payload 換掉這個成本，是同一個訊號在不同信任邊界下的相反判讀，完整推導見 domain event 與狀態流。

可觀察訊號

事件的 payload 從「哪本書、什麼時間」這類事實欄位，長出「現在的全貌」這類當前狀態欄位，是判讀的觸發點；判讀不看 payload 胖不胖，看消費者是不是跟事件來源在同一個信任邊界——邊界內是錯位、邊界外是正當設計。

設計責任

event-carried state transfer 換來的是下游服務不必為了拿到完整資訊而同步呼叫來源，代價是事件 payload 的 schema 跟著狀態演進、下游要一起處理相容性。這個代價只有在真的省下跨服務同步查詢時才划算，同進程情境沒有這筆成本可省，應優先考慮 state stream。

觸發場景：Flutter 書籍管理 App 的事件驅動架構修正系列排了一張票：統一 use case 流程圖裡的事件命名——記錄顯示 UC-02 用了 book_imported、UC-04 用了 data_exported，違反 PascalCase + 過去式規範 疑問來源：事件命名規範裡「過去式」這條，是風格偏好還是有語意依據？以及這張票最後的結局為什麼是「終止」？ 整理目的：記下事件 vs 命令的命名分界、過去式自動檢查的脆弱性、以及「執行前驗前提」的止損實錄 本文邊界：素材是該專案 v0.12-C.4 的設計與終止記錄；這張票停在設計階段、命名規範本身是它留下的產物

過去式不是風格：它標記「這是事實、不是指令」

規範的反例清單值得逐個讀，因為四個反例的病因不同：

1class BookImported extends DomainEvent { }   // 正確：已發生的事實
2class book_imported extends DomainEvent { }  // 錯：風格（snake_case）
3class BookImport extends DomainEvent { }     // 錯：現在式、看不出已發生
4class ImportBook extends DomainEvent { }     // 錯：動詞開頭——這是命令的形狀
5class book extends DomainEvent { }           // 錯：沒有業務語意

第一個反例是純風格問題、lint 就能管。真正的語意分界在第三個：ImportBook 是命令（command）的命名形狀——「去匯入這本書」，接收者要對它做事、可以拒絕、可以失敗；BookImported 是事件（event）——「這本書已經被匯入了」，它是不可否認的歷史事實，訂閱者只能對事實做反應、沒有拒絕的位置。

兩種訊息的責任結構完全不同（命令有唯一的處理者與成敗、事件有任意多的訂閱者且無所謂失敗），而讀者第一眼接觸的就是名字。動詞開頭的「事件」會讓訂閱者用命令的心智模型寫處理邏輯——以為自己能影響流程、以為失敗會被重試。過去式把類別烙在名字上：看到 Imported 就知道木已成舟。

字尾清單抓不住語意：偵測與判定的老分界

規劃中的自動檢查用字尾清單判定過去式：

1final pastTenseEndings = ['ed', 'ted', 'ned', 'ched', 'ded'];

這個啟發式的兩面漏洞都很典型：不規則動詞全部漏接（Sent、Built、Run 的過去式形態沒有 ed 字尾）、而碰巧以 ed 結尾的非過去式會被誤放。它能當候選過濾器（抓出 BookImport 這類明顯缺字尾的）、當不了判決——「這個名字是不是過去式的事實陳述」終究是語意判斷。這跟寫作 lint 的 keyword bank 命中是候選不是判決、跟函式長度規則是觸發器是同一條分界的第三個現場：可機械化的是偵測、不可機械化的是判定，把前者當後者用就會又漏又誤。

版本的結局：前提不存在、0.3 小時止損

這張票最後沒有修任何檔案——Phase 1 的設計審查去核對「待修正」的流程圖時發現：UC-02 的流程圖實際寫的是 BookImportedEvent、UC-04 是 ExportCompletedEvent，早就符合規範。票面宣稱的 snake_case 問題來自過時的工作日誌記錄，實際問題不存在。決策是終止版本、總耗時 0.3 小時。

這是「執行前驗前提」最便宜的一次勝利：如果跳過核對直接進 TDD 四階段，會為一個不存在的問題走完測試設計與實作流程。它跟 stale ticket 考古（58 天票、路徑與數量全漂移）是同一條紀律的兩次實證——工作項的內文是建立當下的快照、執行前重驗每一個事實聲明。而終止決策記錄本身也做對了一件事：把「為什麼不做」跟兩個選項的否決理由寫下來（改成 Event 後綴標準化的提案被否決：後綴是風格、不符架構修正系列的定位），下一個看到這張票的人不會重開一輪。

附帶的懸念也誠實地留著：實際文件用了 Event 後綴（BookImportedEvent）、規範範例沒有（BookImported）——這個不一致被看見、被評估為風格層、被明確地不處理。跟靜默的不一致相比，「已知、已評估、不處理」是完全不同的狀態。

判讀徵兆

• 事件類別的名字以動詞開頭——它長成了命令，訂閱者會用錯誤的心智模型消費它
• 事件與命令在同一個 bus / 同一個目錄裡混居且命名無法區分——先立命名分界、再談架構
• 命名檢查用字尾 / 前綴清單且被當成判決——降級為候選過濾器、命中後人工判定
• 修正類工作項的「問題描述」超過幾週沒被重驗——執行前先花十分鐘核對問題還在不在

相關閱讀

• 同紀律的另一現場：溢出 714px 的 stale ticket 考古——票面快照 vs 現實的漂移
• 偵測 / 判定分界的原則層：#149 keyword bank 命中是候選、不是判決
• 概念地基：DDD 領域驅動設計指南——事件建模章節；事件與命令的責任結構差異是「從操作推導領域」的一部分

觸發場景：Flutter 書籍管理 App 的借閱功能（Loan domain）建立借閱記錄前要查書籍資訊，流程圖直白地畫著 LoanService --> BookRepository——Loan domain 直接摸進 Library domain 的 repository 疑問來源：架構修正把它改成事件驅動的 request/response（BookInfoRequested / BookInfoProvided）。解耦成立了，但設計規格裡多出 requestId、waitFor、timeout、三條錯誤路徑——這些複雜度是必要代價、還是選錯工具的訊號？ 整理目的：把「事件驅動解耦」的帳單攤開、跟替代選項（消費端 Port）比價、收斂出選擇判準 本文邊界：素材是該專案 v0.12-C.2 的設計規格（流程圖與事件介面層級、未及實作）——本文是架構決策推導、不是實測事故

問題：依賴方向錯了

LoanService 直接呼叫 BookRepository（Library domain 的資產）的問題有三層：Library 的變更會波及 Loan、Loan 的測試被迫載入 Library 的實作、兩個 domain 的邊界在這條呼叫上糊掉。這是依賴倒置（DIP）的標準違反現場——高層的業務流程直接抓住了別人家的低層實作。

要修的東西很明確。值得慢下來的是修法的選項空間，因為這次選的路線把帳單放大了。

事件驅動版：每一項都是同步呼叫免費附贈的

修正設計把一次查詢改成一趟事件往返：

1LoanService  --> EventBus: 發布 BookInfoRequested(bookId, requestId)
2EventBus     --> LibraryService: 訂閱並處理
3LibraryService --> EventBus: 發布 BookInfoProvided(bookInfo, requestId)
4EventBus     --> LoanService: waitFor 收到回應（5 秒 timeout）

耦合確實消失了——Library 完全不知道 Loan 存在。但設計規格裡跟著出現的機制、逐項對照同步呼叫：

這張表的形狀有個名字：用事件通道手工重建 RPC。事件的天然語意是通知——「事情發生了」、fire and forget、任意多訂閱者、無所謂回應；request/response 的語意是對話——一問一答、有超時、有失敗。把對話硬放上通知通道，correlation、timeout、錯誤回傳這些 RPC 基礎設施就得自己蓋一遍，而且每個跨 domain 查詢點都要再蓋一遍。

便宜的替代：消費端 Port

解「依賴方向」有更便宜的工具、而且同專案後來自己用過——Port 介面：Loan domain 宣告自己需要的能力、Library 提供實作、組裝層接線：

1// Loan domain 內：宣告需求（依賴方向：Library 實作向 Loan 的介面靠）
2abstract class BookInfoPort {
3  Future<BookInfo?> getBookInfo(String bookId);
4}

DIP 同樣成立（Loan 不認識 Library、只認識自己定義的 Port）、測試同樣乾淨（mock 一個單方法介面）、而呼叫還是一次普通的 await——requestId、timeout、事件錯誤路徑全部不需要。

那事件版買到的是什麼？兩樣 Port 給不了的：時間解耦（發布者不等回應、雙方可以不同時在線——分散式或背景處理的前提）跟基數解耦（一個事件任意多訂閱者）。判準因此收得很乾淨：

• 要解的是依賴方向（單機、同進程、一問一答）→ Port，付介面一張的價
• 要解的是時間或部署（跨進程、離線佇列、多方反應）→ 事件，correlation 與 timeout 是這個量級問題的合理成本

這個 case 的查詢是同進程、一對一、呼叫端必須等到答案才能往下走——三個特徵全部指向 Port。事件版不是錯（它也真的解了耦）、是用了下一個量級的工具付了下一個量級的帳。

判讀徵兆

• 事件名成對出現 XxxRequested / XxxProvided 且帶 correlation id——你在事件通道上做 RPC，先問「需要時間解耦嗎」
• 發布事件之後 waitFor / await 回應才能繼續——呼叫端語意上是同步的，事件只是繞路
• 跨 domain 呼叫的替代方案清單裡沒有「消費端 Port」——選項空間漏了最便宜的一格
• 反向確認：訂閱者不只一個、或處理可以離線 / 延後——這時事件才是本命，別退回 Port

相關閱讀

• 便宜選項的實戰：mock 55 個方法只用 5 個：Port 介面——同專案後期用 Port 解依賴的完整記錄
• 事件的正確場合：Domain Event 命名的過去式——事件是已發生的事實、BookInfoRequested 這個名字本身就洩漏了它其實是請求不是事實
• 概念地基：DDD 領域驅動設計指南——跨領域邊界與事件建模；工具量級的選擇也是「從操作推導」的一部分