トレーディングシステムのためのソフトウェア工学デザインパターン

金融ソフトウェアの失敗は高くつきます。重複注文、不整合な残高、静かに発生する部分的な失敗。デザインパターンはトロフィーではありません——繰り返し発生する障害パターンへの対応です。監査可能性のためのイベントソーシング、読み取りと書き込みを別々にスケールさせるためのCQRS、連鎖的な障害を止めるためのサーキットブレーカー、そしてリトライが二重取引を生まないようにするための冪等性（idempotency）です。

マッチングエンジン、リスクチェック、マーケットデータのパブリッシャーは、巨大な絡み合ったコードの塊の中で互いを直接呼び出すべきではありません。パブリッシュ／サブスクライブバスを使えば、マッチャーがフィルを発行し、下流のサービスはアップストリームの実装の詳細を知らずにサブスクライブできます——ただし、配送保証（少なくとも1回配送 vs 正確に1回配送）とリプレイのための保持期間は必ず選択する必要があります。

サーキットブレーカーは、依存先のサービスが繰り返し失敗している場合に呼び出しを停止し、その依存先に回復する時間を与えつつ、あなたのスレッドプールを保護します。バルクヘッドはリソースプールを分離し、暴走した分析ジョブが注文送信を飢餓状態にしないようにします。

注文や送金には、法的なライフサイクルがあります。許可された遷移を有限状態機械（FSM）としてエンコードすることで、無効な遷移を不可能にします。それを、クライアントのリクエストに付与する冪等性キーと組み合わせることで、ネットワークのリトライが重複したライブ注文を生み出さないようにします。

中央集権型の取引所は、着信する注文を、プライスタイム優先で待機中の流動性とマッチングします。オンチェーンのマッチャー（多くの L1 DEX の設計にみられるような）は決定的でなければなりません。すべてのバリデーターが同じ一連の処理を再実行し、同一の状態に到達します——GaiaExは、このモデルを Hyperliquid のルールから引き継いでいます。

初日からすべてのパターンをカーゴカルト的に導入しないでください。まずは明確な境界、構造化されたログ、そして資金の移動に関するテストから始めましょう。突合作業に痛みが出てきたらイベントログを追加し、外部 API が不安定になってきたらサーキットブレーカーを追加します。パターンは想像上の擦り傷ではなく、実際の擦り傷を解決するためのものです。