12. ライブトレーディング S1.3 の設計哲学とアーキテクチャ

この記事では、設計の観点から、S1.3 のライブトレーディングリファクタリングアプローチ、つまり階層化がこの方法で行われる理由、互換性がどのように維持されるか、およびこれらの設計が将来の拡張機能にどのように役立つかを説明します。

12.1. 0. 文档定位

この文書は設計仕様書であり、ユーザーチュートリアルではありません。
「段階的にどのように運用するか」ではなく、「なぜこのようにするのか」に答えることに重点を置いています。
実践的なパスが必要な場合は、live_trading/2-configuration-and-run.md および tutorials/8-live-trade-risk-and-broker-walkthrough.md にアクセスしてください。

S1.3 のライブ関連の責任は次のように抽象化できます。

「構造が間違っている場合でも実行される」ことによって引き起こされるサイレントエラーを回避するために、境界で順序 dict と fill dict を検証します。

リスク評価はデータベースに書き込んでキューに入れる前に完了するため、拒否された注文によって実行データが汚染されることはありません。

ブローカーアダプター API を介して将来の統合を実行し、Trader と特定のブローカーシステム間の結合を軽減します。

拒否の理由は、rule_id および英語の reason を介して外部から確認でき、作戦検索とインシデント後のレビューをサポートします。

可視性 (CLI/TUI の概要 + ログ) を向上させながら、下位互換性を維持します (拒否は空の結果として表示される場合があります)。

ワンショット移行による回帰リスクを回避するために、レガシーキューの互換性パスを維持します。

部分充填シナリオでは、ユーザーが観察する意味上の矛盾を減らすために、ステータスは累積充填量に基づく必要があります。

S1.3 はブローカー統合のエンドポイントではなく、基礎となる基盤です。