事件驅動的精神是責任反轉：不是「Order 命令 Notification 寄信」，而是「Order 廣播『訂單完成』事件，Notification 自己決定要不要寄信」。發佈者不知道、也不需要知道誰在聽——這讓系統最鬆耦合。
🧠 Core Ideas
TIP
先決定通訊風格再選技術——很多微服務專案栽在「先選技術再想需求」（拿 Kafka 硬做請求/回應）。決策路徑：① 同步還是非同步？同步幾乎必然走請求/回應。② 選非同步的話，是事件驅動、非同步請求/回應、還是共用資料？
- 事件 (Event) ＝已發生事實的陳述（語義/內容）；訊息 (Message) ＝傳輸載體。廣播時把事件包進訊息。
- 事件驅動本質非同步，帶來時間解耦；責任分散到各訂閱者，契合自治團隊的組織思維。
⚖️ 五種通訊風格
同步阻塞 vs 非同步非阻塞
- 同步阻塞：心智模型熟悉（SQL、HTTP 呼叫），但綁時間耦合（下游要在線）、下游慢上游一起慢、易級聯失敗。
- 非同步非阻塞：時間解耦、適合長時間工作（倉庫揀貨可能數小時），但心智負擔重、有非同步特有的坑。
- NOTE：
async/await不一定真非同步——JS 的await對呼叫端視角仍是阻塞。
請求/回應：指令 vs 請求
- 同步實作＝開連線等回應；非同步實作＝經 broker 排隊，接收端要知道回覆送哪（reply queue），上游要把回應對回原請求。
- 作者偏好「請求 (request)」而非「指令 (command)」——指令暗示必須執行，請求允許下游依自身邏輯拒絕。微服務應有權拒絕無效請求。
共用資料通訊
- A 寫到共用位置、B 之後讀（Data Lake / Data Warehouse）。技術門檻低、能橋接老舊系統、大批量不是問題。
- 缺點：通常高延遲（輪詢）、共用儲存成耦合源、韌性受限於底層儲存。
⚖️ 事件裡該放什麼？
只放 ID vs 放完整資訊
- 只放 ID：接收者還要回頭呼叫來源取資料 → 增加領域耦合；大量訂閱者同時回問會把來源打爆。
- 放完整資訊（作者偏好）：接收者更自給自足、耦合更鬆，事件還能兼作歷史紀錄（配合事件溯源）。
- 代價：事件變成對外契約，刪欄位會破壞外部消費者；且要注意敏感資料（PII、信用卡）擴散。
WARNING
事件驅動最鬆耦合，但帶來新一類坑：訊息中毒、重試風暴、難追蹤。入場券是——最大重試次數、死信佇列 (dead letter queue)、關聯 ID (correlation ID)、比同步系統更強的監控。Martin Fowler 稱失控的重投為「災難性的故障轉移」。
🔑 Takeaways
- 事件驅動 = 責任反轉 + 時間解耦，是最鬆耦合的風格。
- 先選風格再選技術；同步→請求/回應，非同步→事件驅動/非同步請求回應/共用資料。
- 事件 payload 傾向放完整資訊（自給自足、耦合鬆），但要管好對外契約與敏感資料。
- 鬆耦合不是免費的：DLQ、重試上限、關聯 ID、監控缺一不可。
No notes yet — jot your takeaways or Q&A here.