設計交易系統的訂單對象

我想設計我的第一個交易系統，並且我正在努力設計一個正確的訂單對象，其中涉及到所有FIX概念。想知道是否有經驗豐富的人可以在一些想法中插話。設計交易系統的訂單對象

我創建了一個簡單的Order類。但作爲NewOrderSingle（FIX）生成，我需要一個ClOrdId。然後當我取消這個訂單時，我需要一個新的ClOrdId（對於每個取消和替換生成的FIX消息）並設置正確的OrigClOrdId。所以我需要跟蹤那些OrigClOrdIds。

此外，我認爲我需要在系統中保留一個唯一的ID以識別此訂單，與ClOrdId不同，後者可能會不斷變化。

我沒有看到任何很好的面向對象的設計這個順序對象的方式，同時保持與我的FIX消息相關的各種Ids的概念是分開的。

人們在現實世界中如何設計這些？有什麼建議麼？謝謝。

來源

2012-10-02 endless

（http://www.quickfixj.org/）QuickfixJ是一個開源庫。您可以通過它進行檢查並繪製出您自己的實施細節。 – DumbCoder

這個類圖怎麼樣？

Order class diagram

取消方法構造新SubOrder可用於發送取消請求。您可以爲其他子訂單類型添加更多構造函數方法。如果取消訂單非常具體，您可以爲每個訂單類型創建一個類，如果他們有共同點，他們可以擴展普通類，例如AbstractOrder。類似的東西：

Class diagram with generalization

來源

2012-10-02 23:30:45

謝謝。一個瑣事......你用什麼UML s/w？ – endless

@ user1364959 [yEd]（http://www.yworks.com/en/products_yed_about.html）它不完全是UML工具，但它是免費的。 –

我已經參與了幾個系統已經做你所描述的正是設計。它實際上比設計類層次結構更復雜。請注意以下幾點：

根據交易場地和/或資產類別，訂單的「唯一ID」實際上可能是標籤的組合。例如，在紐約證券交易所「經典」交易時，唯一ID實際上是由標籤115（OnBehalfOfCompID）+標籤11組成的複合ID。對於其他場所，可能是標籤109 +標籤11或標籤76 +標籤11.

此外，您可能需要向您的唯一ID添加更多數據，以說明發送到不同場館的ID可能相同。例如，一些場館需要Integer作爲它們的ClOrdID值。在這種情況下，您對「唯一ID」的內部表示應該是某種鹽+ ID數據，即DARKCROSS-1，其中（虛構）場所是「黑客」，1是標記11的值。

如果幾個場所有類似的策略來解決訂單的唯一ID，那麼您可以將該邏輯抽取到ID工廠 - 組合繼承。因此，您的抽象可以從AbstractOrder開始，但是您可能會發現需要有NyseOrder,NasdaqOrder等等。（請注意，我看到的一些實現有一個GenericFixOrder類或類似的東西。實際上，沒有這樣的東西 - 每個地點都有自己的特定行爲，與其他行爲有所不同。）

另一個主題是Good Til Cancel和Good Til日期訂單，通常必須具有所有時間唯一的ID（即ID必須包含日期），以及在多次重新啓動時應用程序能夠存活的ID。所以，您的ID工廠必須考慮這些訂單。

關於ID的關係，它實際上非常簡單。您有一個Map的唯一訂單ID到Order對象。表示取消/替換或取消的類引用父訂單（通過「父訂單ID」字段，與上述的「唯一ID」字段解析相同）。

沒有必要直接引用原始（「根」）新訂單，實際上，當接受取消/替換時，您可能會發現將它從持有您訂單的Map中移除是有益的。當取消被接受時，您幾乎可以肯定地從Map中刪除它和訂單 - 訂單已完成。

請注意，以上是一般草圖 - 從內存中刪除訂單等可被視爲過早優化。如果您的交易量很小，那麼您可能在整個一天內都將所有的交易信息保存在內存中。

來源

2012-10-09 13:49:12 noahlz

設計交易系統的訂單對象

回答

相關問題