为交易系统设计订单对象

Question

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

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

此外，我认为我需要在系统中保留一个唯一的ID内部来识别此订单，这与ClOrdId不同，后者可能会不断变化。

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

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

Answer 1

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

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

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

如果有几个场所有类似的策略来解析订单的唯一ID，那么您可以将该逻辑提取到ID工厂中 - 合并而不是继承。

因此，您的抽象可以从AbstractOrder开始，但您可能会发现需要NyseOrder，NasdaqOrder，等等。

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

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

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

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

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

Answer 2

这个类图怎么样？

取消方法构造可用于发送取消请求的新SubOrder。您可以为其他子订单类型添加更多构造函数方法。如果取消订单非常具体，您可以为每个订单类型创建一个类，如果它们有共同点，则可以扩展公共类，例如AbstractOrder。这样的事情：