交易系統的軟體工程設計模式

金融軟體出錯的代價很高：重複下單、餘額不一致、悄無聲息的部分失敗。設計模式不是用來擺設的獎盃——它們是針對反覆出現的失敗模式的應對方案：用事件溯源實現可審計性，用 CQRS 讓讀取與寫入分別獨立擴充套件，用熔斷器阻止連鎖宕機，用冪等性確保重試不會造成重複交易。

撮合引擎、風險檢查和行情釋出器之間不應在一團亂麻裡互相直接呼叫。一條釋出/訂閱匯流排讓撮合引擎只管發出成交，下游服務可以訂閱，而無需瞭解上游的實現細節——但你仍然必須選擇投遞保證（至少一次 vs 恰好一次）以及供重放使用的保留策略。

熔斷器在反覆失敗後停止呼叫一個生病的依賴，給它恢復的時間，同時保護你的執行緒池。隔板隔離資源池，使一個失控的分析任務無法把下單提交餓死。

訂單和轉帳有合法的生命週期。把允許的狀態轉移編碼進有限狀態機，讓非法跳轉無法發生。再為客戶端請求配上冪等鍵，這樣網路重試就不會建立出重複的有效訂單。

中心化交易場所按價格-時間優先，把新進訂單與掛在簿上的流動性撮合。鏈上撮合器（如許多 Layer 1（一層 / 主鏈）DEX 的設計）必須是確定性的：每個驗證者重新執行同一序列，併到達完全相同的狀態——GaiaEx 從 Hyperliquid 的規則中繼承了這一模型。

不要在第一天就盲目照搬每一個模式。先從清晰的邊界、結構化日誌，以及圍繞資金流動的測試做起。當對帳的痛苦出現時再加上事件日誌；當外部 API 不穩定時再加上熔斷器。模式解決的是真實的擦傷，而不是想象出來的傷。