java - 为交易系统设计 Order 对象

Question

我正在尝试设计我的第一个交易系统，并且正在努力设计一个正确的 Order 对象，其中包含所有 FIX其中涉及的概念。想知道是否有任何有经验的人可以提出一些想法。

我创建了一个简单的 Order 类。
但作为NewOrderSingle (FIX) 生成，我需要一个 ClOrdId .
然后当我取消这个订单时，我需要一个新的ClOrdId (对于生成的每个取消和替换 FIX 消息)并设置正确的 OrigClOrdId .所以我需要跟踪那些 OrigClOrdIds .

另外，我认为我需要在我的系统内部保留一个唯一的 Id 来识别这个订单，不同于 ClOrdId ，这可能会不断变化。

我没有看到任何很好的面向对象的设计这个订单对象的方法，同时保持与我的 FIX 消息相关的各种 Id 的概念分开。

人们如何在现实世界中设计这些？有什么建议吗？谢谢。

Answer 1

我参与了几个系统的设计，这些系统完全符合您的描述。它实际上比设计类层次结构更复杂。要记住的一些事情:

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

此外，您可能需要向您的唯一 ID 添加更多数据，以解决发送到不同场所的 ID 可能相同的事实。例如，某些 field 需要Integer作为他们的 ClOrdID 值。在这种情况下，“唯一 ID”的内部表示应该是某种盐 + ID 数据，即 DARKCROSS-1 (虚构的) field 是“DARKCROSS”和1是标记 11 的值。

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

所以，你的抽象可以从 AbstractOrder 开始，但你可能会发现你需要有 NyseOrder , NasdaqOrder ，等等。

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

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

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

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

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