IEngine (Backtest, Simulation, Live)

IEngine
IEngine is designed to model the market behavior. There’re three types of engines: backtest, simulation and live.
In common, any market will offer services such as: accepting orders, matching orders, clearing securities, and offers communication channels to market participants.
In each of their own purpose, there’re difference by dessign for each of the IEngine implementations, which is briefed below:
a. BacktestEngine
Each BacktestEngine has its own EventBus (which I called it EBS), facilitating event publication and subscription. Such EBS is not shared at system wise, nor between markets, but instead, isolated within each engine (and accounts registered to the markets) level. The benefit of this design is to enable backtests on multiple engines simoutenously AccountServices, strategies and any one to communicate with the market should rely on the same channel offered by the BacktestEngine.
BacktestEngine gets triggered by date time of historical bars.
b. SimulationEngine
Simulation follows the real market trading time and condition. It gets triggered by live market. For example, live market starts trading at 09:00 am, when MarketOpenEvent gets generated, then as a listener, simulation engine picks up the events and start order matching, with conditions that the OPEN price is already available to simulation engine. In the scenario where the live price is not available, we can delay the matching process until the open price is available.
c. LiveEngine

Detailed functions provided by IEngine as following:

1. accept orders
   Market receives orders from brokers, so IEngine listens to LocalOrderSubmit events, and update it’s order book. It may perform order validations (i.e. the order has valid price, valid securities code, market is in valid state to accept order and etc), to generate OrderRejected events if there’s validation error. Normally, it geenrates OrderCreatedEvent.
   A scenario would be account “A” submit an buy order to market for 100 for stock “000001” at 17.8; IEngine creates an order internally assigning order_id=001 to it, insert the order to a queue queue internally, and the generates OrderCreatedEvent.
   
2. market ticks under simulation
   In real market, market ticks twice a second with order book snapshot. XAccount will register with market to receive events.
   In simulation mode, IEngine simulates and generates tick events. It loads market snapshot prices based on the simulation granularity. A scenario would be that IEngine simulates under “1h” bar timeframe, when it ticks for bar close, IEngine loads bar close prices for security universe for close prices, and triggers BarCloseEvent.
   
3. match orders
   In backtest, orders in engine get matched under assumption of price+slippage.
   In simulation, orders get matched at OPEN, so that we can track closely to live accounts.
   
4. provide market status and date/time
   An engine maintains its own time and state, because it models the actual market. When there’s an event change, it publishes state change event.
   A typical scenario: at 09:00 am, the engine state is updated to OPEN (it was SOD), with such state change, a MarketOpenEvent is generated and published.
   
5. provide communication channel
   I use “EventBus” to manage all communications. Each engine (either backtest or simulation) has its own EBS defined.
   An engine listens to the bus for specific events. A typical scenario: an account service submits a order at SOD, after which, the engine picks up the order event, and update it’s EngineOrder book with acknowledgment back.
   An engine publishes events to the bus. A typical scenario: at market open, the engine matches all orders and genereates trades, with OrderEvent and TradeEvent published into the bus, from which the account service could maintain its own order book and trade book.