2

I am trying to design my first trading system and I am struggling with designing a correct Order object with all the FIX concepts involved in it. Wondering if any experienced folks can chime in on some ideas.

I created a simple Order class. But as a NewOrderSingle (FIX) is generated, I need a ClOrdId. Then when I cancel this order, I need a new ClOrdId (For every cancel and replace FIX message generated) and set the correct OrigClOrdId. So I need to keep track of those OrigClOrdIds.

Also, I think I need to keep a unique Id internal to my system to identify this order, different from ClOrdId, which could keep changing.

I don't see any nice object oriented way of designing this order object while keeping the concept of various Ids relevant to my FIX messages separate.

How do people design these in real world? Any suggestions? Thanks.

4

2 回答 2

2

我参与了几个完全按照您所描述的系统的设计。它实际上比设计类层次结构更复杂。需要记住的一些事项：

根据交易场所和/或资产类别，订单的“唯一 ID”实际上可能是标签的组合。例如，在纽约证券交易所“经典”交易时，唯一 ID 实际上是由标签 115 (OnBehalfOfCompID) + 标签 11 组成的复合 ID。对于其他场所，它可能是标签 109 + 标签 11，或标签 76 + 标签 11。

此外，您可能需要向您的唯一 ID 添加更多数据，以说明发送到不同场所的 ID 可能相同这一事实。例如，某些场所需要一个Integer作为其 ClOrdID 值。在这种情况下，“唯一 ID”的内部表示应该是某种盐 + ID 数据，即DARKCROSS-1（虚构的）地点是“DARKCROSS”并且1是标签 11 值。

如果多个场所具有类似的解决订单唯一 ID 的策略，您可以将该逻辑提取到 ID 工厂中 - 组合优于继承。

因此，您的抽象可以以 a 开头AbstractOrder，但您可能会发现需要具有NyseOrder,NasdaqOrder等等。

（请注意，我见过的一些实现有一个GenericFixOrder类或一些这样的。实际上，没有这样的东西 - 每个场所都有自己的特定行为，与其他场所略有不同。）

另一个主题是 Good Til Cancel 和 Good Til Date 订单，它们通常必须具有始终唯一的 ID（即 ID 必须包含日期），并且在您的应用程序中多次重新启动后仍然有效。因此，您的 ID 工厂必须考虑到此类订单。

关于ID的关系，它实际上很简单。您有一个对象Map的唯一订单 ID Order。表示取消/替换或取消的类引用父订单（通过“父订单 ID”字段，与上述“唯一 ID”字段解析相同）。

不必直接引用原始（“根”）新订单，事实上，当取消/替换被接受时，您可能会发现将其从Map持有的订单中删除是有益的。当取消被接受时，您几乎可以肯定地从订单中删除它和订单Map- 订单已完成。

请注意，以上是一般草图 - 从内存中删除订单等可能被认为是过早的优化。如果您的交易量很小，您可能会将所有交易信息保存一整天。

于 2012-10-09T13:49:12.230 回答
1

这个类图怎么样？

订单类图

Cancel 方法构造 newSubOrder可用于发送取消请求。您可以为其他子订单类型添加更多构造方法。如果取消订单非常具体，您可以为每种订单类型创建一个类，例如，如果它们有共同点，它们可以扩展通用类AbstractOrder。像这样的东西：

具有泛化的类图

于 2012-10-02T23:30:45.360 回答