08 Oct 2025
I’ve worked on trading systems for a while now, and for various reasons I’ve never got the squeaky clean order model that I’ve always wanted. So there, a java trading model as open source.
There’s always a tension between clean code and good performance, but there’s seldom a good approach to measuring performance, and to evaluating compromises. In the code linked above, the major concession to performance is a “zero garbage” style. This has long been the way to do low latency java: allocate all the objects that you’ll need at startup, and pool them. Then you never need to allocate, and more importantly, to deallocate. So you don’t have to worry about garbage collection pauses. It’d be interesting to see how important this is, now that we have zgc. As you can see, that style it doesn’t even incur much bloat in this code. The inability to statically confirm that an object is really safe to release back to the pool has always bugged me though.
Avoiding both spaghetti code and an order “god object” is a challenge. I don’t have an easy answer. The best I came up with is to have separate objects for the actual domain concepts of “request” and “parent order”, and to have relatively small coupling between them and the rest of the “order” concept. You can explore that by grepping for “protected” fields and methods. (To make that easier, I refrained from using package private visibility.) I tried to be disciplined about the utility of the various IDs. Despite the potential for abuse, I decided that listeners are good for maintaining separation of domain concerns. I took advantage of the FIX hint of “replace” for order modification, that all the fields from the upstream are best as a separate object, which can be replaced almost independently of the system’s order state.
Relatedly, IMHO the Domain Driven Design literature should put more emphasis on making illegal states unrepresentable, or more generally, building a domain model that’s a kind mini-language for working with the domain. I tried to do that with this code, but it’s hard, and even harder to write well about :).
The only other detail I’ll call out regarding this little project is that it’s surprisingly easy to have the business logic be independent of the serialization technology. There’s a demo in the tests; I have trivial code to map between the domain objects and SBEs, I believe without performance compromise. There is very little code which needs to rely on both SBE and domain, and it relieves the domain from relying on SBE. The enums that the domain refers to are in a separate package, so that they can be easily replaced by enums that are generated by SBE. As long as your code doesn’t rely on ordinal() and as long as you exercise each enum value with a unit test, this is perfectly well supported in java. Regarding copying between domain objects and DTOs in general, a simple copy is idiomatic for high performance serialization; you are expected to not hold on to any references to those data transfer objects. Maybe one day I’ll see how this holds up when used “in anger”.
Lastly, I view the difficulty of coming up with this code as an indictment of object oriented programming. Despite the order model being pretty simple in total, and despite the FIX standard being good and ubiquitous, people struggle to come up with clean code for it in real programming environments, whether with agile methodology or with big design up front.
RSS