AlgoTraderAlgoTrader Documentation

Chapter 7. Domain Model

7.1. Entities
7.1.1. Strategy
7.1.2. Security
7.1.3. Market Data Events
7.1.4. Order
7.1.5. Account
7.1.6. Transaction
7.1.7. Position
7.1.8. Cash Balance
7.1.9. Subscription
7.1.10. Exchange
7.1.11. Order Preference
7.1.12. Quote Request and Quote
7.2. Services
7.2.1. Main Services
7.2.2. Client Services
7.2.3. Account Service
7.2.4. Calendar Service
7.2.5. Combination Service
7.2.6. Future Service
7.2.7. Historical Data Service
7.2.8. Market Data Service
7.2.9. Measurement Service
7.2.10. Option Service
7.2.11. Order Service
7.2.12. Portfolio Service
7.2.13. Position Service
7.2.14. Property Service
7.2.15. Reference Data Service
7.2.16. Rfq Service
7.2.17. Market Data Cache Service
7.2.18. Lookup Service
7.2.19. Strategy Service & Config Aware Strategy Service
7.2.20. Subscription Service
7.2.21. Reset Service
7.3. Value Object
7.4. Enumerations

The following sections describe the Domain Model of the system using UML (unified modeling language).

The Main Entities of the system are specified within the following table:

A full list of all Entities of the system will be discussed throughout the next sections. Entities of the system can be categorized into the following three areas:

Reference Data

Represent static referential data like:

Strategy, Security, SecurityFamily, SecurityReference, Account, Property, OrderPreference and related Entities

Market Data

Represent external events (Tick and Bar) coming from market data providers or internal events (Generic Events) coming from another trading strategy. Market Data is typically immutable and of only momentary interest to the trading strategies. Market Data Events are available as Value Objects only (but not as Entities):

MarketDataEventVO and its subclasses TickVO, BarVO, QuoteVO, BidVO, AskVO, TradeVO and GenericTickVO as well as any type of GenericEventVO

Transaction Data

Represent the financial state of trading strategies. Some of them (e.g. Transactions and Measurements) are immutable whereas others (e.g. Positions and Balances) are mutable and change their values while Orders are getting executed:

Order, Transaction, Position, CashBalance, Measurement, PortfolioValue and related Entities

Besides providing Getters and Setters all Entities provide the following common features:

The strategy entity represents an individual strategy running inside AlgoTrader.

Regarding the question "what is a productive strategy?". It essentially up to the user, what he would like to consider as one strategy. A strategy can have one or multiple instruments. And also regarding trading logic there is no limitation.

However please note that the entire performance and reporting functionality of AlgoTrader happens on the strategy level. So if one would like to see performance metrics on an instrument level one would have to instantiate multiple strategies. Also, if it is a requirement to start and stop individual functions separately, it is best to put them into two separate strategies.

On the technical side each separate strategy allocates a certain amount of overhead (memory and CPU). For that reason it is best to combine functionality into as few strategies as possible if there are no good reasons not to separate them.

The field autoActivate means that if a strategy is set to active corresponding market data subscriptions are initiated automatically upon startup of the system. This is useful in distributed mode when strategies and the server run in different processes. If you restart the server in this scenario, subscriptions for the strategies are automatically loaded again (without having to restart the strategies).

There are several classes that are directly related to the strategy

All valuations (strategy and position level) can be queried via the PortfolioService. Fees are considered in the calculations if properly configured.

The above UML Class diagram shows all available Security classes

The Security class provides the following two important methods:

  • getValue which calculates the current (market) value of the instrument based on a quantity and a price parameter

  • getPrice which calculates the current price of the instrument based on a (market) value and a quantity parameter

For most instruments the formula is:

  • value = quantity x contractSize x price

  • price = value / quantity / contractSize

However for PerpetualSwaps the formulas are different:

  • value = quantity x contractSize / price

  • price = quantity * contractSize / value

A Security Family contains common information about an entire family of securities (i.e. all general information about options on S&P500 are stored using this class). The class provides fields like MIN_QTY, MAX_QTY and MIN_PRICE. This information is used by ReferenceDataService when downloading new future and option changes, values from Security Family will then be copied onto the newly created Futures and/or Options. In regular operation mode (i.e. simulation of live trading) the information from Security Families are not used but only the information contained within Securities.

SecurityReference Is a generic link between one security the owner and another the target. Using this class it is possible for a Security to have links to multiple other Securities.

The following UML Class diagram shows the Order and its related subclasses.

Table 7.6. Order Classes

OrderBase Class for all Order Types
OrderStatusOrder Status changes received back from the Broker / Exchange (e.g. PARTIALLY_EXECUTED or CANCELLED) are represented by this class
OrderCompletionSimilar to Order Status but only gets created once an order is fully executed or cancelled and all corresponding database activity has been completed.
OrderPropertyAn arbitrary property that can be attached to an Order. Through the type attribute the OrderProperty can be marked as internal only or as fix property or as IB property.
FillFilled orders are represented by this Class
TransactionEach Fill is recorded as a transaction in the database using this entity. In addition the table transaction also carries transactions like INTREST, DEBIT, CREDIT & FEES
SimpleOrderAn Order that can be sent directly to the market
MarketOrder Predefined SimpleOrder types
AlgoOrderA composite order that will generate multiple SimpleOrders. An AlgoOrder cannot be sent directly to the market. AlgoOrders are also called "Execution Algos", see Chapter 23, Execution Algos
TWAPOrderThis algorithm aims to match the Time-Weighted Average Price
VWAPOrderThis algorithm aims to match the Volume-Weighted Average Price
TargetPositionOrderThis algorithm automatically manages orders to reach the specified target quantity.
TrailingLimitOrderThis algorithm submits an order directly to the broker/exchange, with a limit price set a fixed distance from the current market price.
SlicingOrderAn AlgoOrder, that will split a large order into multiple child orders. The size of the child order, time in the market and delay between orders are randomized within the specified range.


AlgoOrders and Order parent/child associations are persisted to the database. After a system restart, pending AlgoOrder will be visible but it will not continue execution automatically - it will not create new child orders. Execution reports for existing child orders will be processed.

An Account represents either an actual account, an account group (IB specific) or an allocation profile (IB specific). An account is assigned to a particular adapterType (e.g. IB_NATIVE or FXCM_FIX) which identifies the OrderService to use for this account. In addition the field sessionQualifier which is needed to define the actual session in place (for FIX Connections). With this setup, it is possible to have multiple Sessions (session qualifiers) per AdapterType and to have multiple Accounts per Session. If the field active is set to true a potential corresponding Fix session will be activated.

Optionally an accountServiceType (e.g. IB_NATIVE or BFX) can be added which identifies the AccountService to use for this account.

Accounts have an optional dependency to Exchange for cases when an account can only be used to trade on one single Exchange (typical for Crypto Currency Exchanges).

The system is based on a Service Oriented Architecture (SOA). All operations of the system are provided as Spring Services / Beans. The following groups of services exist:

For a full list of all Services please visit our JavaDoc

Inside strategies all services are injected by the Spring Framework and can be accessed as follows withing the strategy service:

// subscribe for live market data

getSubscriptionService().subscribeMarketDataEvent(strategyName, securityId, adapterType);
// lookup a instrument by symbol
// send an order to the broker or exchange

The CalendarService is responsible for providing information about Exchange trading hours and holidays.

Especially when trading multiple exchanges around the globe the CalendarService becomes very useful. It provides convenient methods like:

In addition the Calendar service provides methods to identify a particular trading day, which will be important to associate a particular order for clearing. If a trading session overlaps from one day to another (e.g. starts on Sunday 23:00pm), the trading day will be considered the day when the session ends (e.g. Monday). However in this example Monday would need to be set to true in the corresponding TradingHours object.

AlgoTrader provides several Historical Data Interfaces out-of-the-box. The system can store historical data in the integrated Section 18.1, “InfluxDB” and feed stored or recorded historical data to strategies during back tests. The system also integrates a feature for live data recording as well as live tick-to-bar aggregation. For further details please see Chapter 18, Historical Data

In contrast to Entities which are used to persist information, Value Objects are typically used for transmitting objects (e.g. via JMS or RMI). For each Entity a corresponding Value Object is generated. Value Objects are immutable (i.e. all fields are final and need to be set through the constructor)

Each Entity contains an inner Converter class that can be used to convert the Entity to its corresponding Value Object.

In addition to Value Objects ValueObjectBuilders exist which help creating Value Objects. Example:

MarketOrderVO order = MarketOrderVOBuilder.create()


For a full list of all Value Objects please visit our JavaDoc

For selectable items with a fixed number of choices AlgoTrader contains Java 5 Enumerations. For a full list of all Enumerations please visit our JavaDoc