The writing is on the wall…
— Daniel 5 (ref)
核心概念#
想像偵探們如何使用黑板來協調和破解一樁謀殺案。總督察在會議室架起一面大黑板，寫上一個問題：
H. Dumpty（男性，蛋）：意外？謀殺？
Humpty 到底是自己摔的，還是被推的？每個偵探都可以為這個潛在的謀殺案做出貢獻——加入事實、證人陳述、法醫證據等等。隨著資料累積，偵探可能注意到某個關聯並張貼觀察或推測。這個過程持續進行，跨越所有班次、不同的人和代理人，直到案件結案。
黑板方法的關鍵特性#
| 特性 | 說明 |
|---|---|
| 偵探不需要知道其他偵探的存在 | 他們只是監看黑板上的新資訊，然後加入自己的發現 |
| 偵探可能受過不同訓練 | 有不同的教育水平和專業知識，甚至不在同一個轄區工作。他們共享的只是破案的渴望 |
| 不同的偵探可能隨時加入或離開 | 可能值不同的班 |
| 黑板上可以放任何東西 | 圖片、句子、實物證據等 |
這是一種自由放任式（laissez faire）的並行。偵探們是獨立的程序、代理人、actor 等。有些在黑板上存放事實，有些從黑板上取走事實進行處理或結合，然後加入更多資訊。黑板逐漸幫助他們得出結論。
黑板系統的歷史#
早期的電腦黑板系統主要用於人工智慧應用——語音辨識、知識推理系統等。其中一個最早的黑板系統是 David Gelernter 的 Linda，它以 typed tuples 儲存事實，應用程式可以寫入新的 tuple 並透過模式比對查詢既有的 tuple。
後來出現了分散式的黑板系統如 JavaSpaces 和 T Spaces，可以儲存活動的 Java 物件並透過欄位的部分匹配或子型別來檢索。但這些系統從未真正流行，部分原因是當時對並行協作處理的需求尚未發展起來。
黑板的實際應用#
書中以一個處理抵押貸款或貸款申請的程式為例。此領域的法規極其繁雜，聯邦、州和地方政府各有規定。貸款方必須證明他們已揭露某些事項、必須要求某些資訊，但又不能問某些問題。
除了法規之外，還有許多實際問題：
- 回應可能以任意順序到達（信用查詢可能花很長時間，但姓名地址立即可得）
- 資料收集可能由不同辦公室、不同時區的不同人完成
- 某些資料收集可能由其他系統自動完成，非同步到達
- 某些資料依賴其他資料（例如需要先有擁有權證明才能開始產權搜尋）
- 新資料的到來可能引發新的問題和政策
你可以嘗試用工作流系統處理所有可能的排列組合，但這些系統通常既龐大又需要大量程式設計師維護。當法規改變時，工作流程必須重組，程式碼可能需要重寫。
黑板搭配規則引擎來封裝法律要求，是優雅的解決方案。資料到達的順序無關緊要：當一個事實被張貼時，它可以觸發適當的規則。回饋也容易處理：任何規則集的輸出可以張貼到黑板上，觸發更多適用的規則。
Tip 60 - Use Blackboards to Coordinate Workflow（使用黑板來協調工作流程）
訊息系統可以像黑板#
現代許多應用程式使用小型、解耦的服務，透過某種訊息系統（如 Kafka、NATS）溝通。這些訊息系統不只是從 A 到 B 傳送資料——它們提供持久化（以事件日誌的形式）和透過模式比對檢索訊息的能力。這意味著你可以將它們同時用作黑板系統，也可以作為執行一群 actor 的平台。
但事情沒那麼簡單#
Actor 和/或黑板和/或微服務架構移除了應用程式中一整類潛在的並行問題。但這個好處是有代價的：
- 推理更困難：許多行為是間接的。你會需要維護一個訊息格式和/或 API 的中央資料庫，最好能自動產生程式碼和文件
- 需要好的工具來追蹤訊息和事實在系統中的流動。一個有用的技巧是在業務功能啟動時加入唯一的 trace id，然後傳播給所有相關的 actor，如此就可以從日誌檔中重建事件
- 部署和管理更麻煩：因為有更多的移動部件。但某種程度上，系統更細粒度、可以替換個別 actor 而非整個系統，也抵消了這一點
相關章節#
- Topic 28，去耦合
- Topic 29，在現實世界中玩雜耍
- Topic 33，打破時間耦合
- Topic 35，參與者與程序