私は、あなたが説明していることを正確に行ういくつかのシステムの設計に携わってきました. 実際には、クラス階層を設計するよりも複雑です。注意事項:
取引所および/または資産クラスに基づいて、注文の「一意の ID」は実際にはタグの組み合わせである場合があります。たとえば、NYSE「クラシック」で取引する場合、一意の ID は、実際にはタグ 115 (OnBehalfOfCompID) + タグ 11 で構成される複合 ID です。他の取引先では、タグ 109 + タグ 11、またはタグ 76 + タグ 11 になります。
さらに、異なる会場に送信された ID が同じである可能性があるという事実を説明するために、一意の ID にさらにデータを追加する必要がある場合があります。たとえば、一部の会場では、IntegerClOrdID 値として が必要です。このような場合、「一意の ID」の内部表現は、ある種のソルト + ID データにする必要があります。つまりDARKCROSS-1、(架空の) 会場は「DARKCROSS」で1あり、タグ 11 の値です。
複数の会場で注文の一意の ID を解決するための同様の戦略がある場合、そのロジックを ID ファクトリ (継承よりも構成) に抽出できます。
したがって、抽象化を で始めることもできますが、 、 などAbstractOrderを含める必要があることに気付くかもしれません。NyseOrderNasdaqOrder
(私が見たいくつかの実装には、GenericFixOrderクラスなどがあることに注意してください。実際には、そのようなものはありません。各会場には、他とはわずかに異なる独自の特定の動作があります。)
もう 1 つのトピックは、Good Til Cancel 注文と Good Til Date 注文です。これらは通常、常に一意の ID (つまり、ID には日付が含まれている必要があります) が必要であり、アプリケーションを複数回再起動しても存続します。したがって、ID ファクトリはそのような順序を考慮に入れる必要があります。
ID の関係については、実際には非常に簡単です。Mapオブジェクトに対して一意の注文 ID がありますOrder。キャンセル/交換またはキャンセルを表すクラスは、親注文を参照します (「親注文 ID」フィールドを介して、上記の「固有 ID」フィールドと同じように解決されます)。
元の (「ルート」) 新規注文を直接参照する必要はありません。実際、キャンセル/交換が受け入れられた場合Map、注文の保留から削除することが有益である場合があります。キャンセルが受け入れられると、ほぼ間違いなくキャンセルと注文の両方を から削除できますMap。注文は完了です。
上記は一般的なスケッチであることに注意してください。メモリから注文を削除するなどは、時期尚早の最適化と見なすことができます。取引量が少ない場合、すべての取引メッセージを 1 日中メモリに保持することができます。
