![\"Organized](\"/files/domain-market-0569a45438243c4a89593c703e17634a.png\")
Organized market model
So far, we have been talking about market events, orders and strategies, as\nabstract concepts, leaving details to a later point. Now, to design the core of\nthe strategy engine, we need the full picture.
\n--- excerpt ---
\nIt is time to descend into details. We will now define the interfaces that define our\nbusiness logic's view on the world. That is, the ports it uses:
\n\n\n\n
\n- Market port (this post).
\n- Trading port.
\n- Other strategy ports.
\n
As we defined in the modules and components post, the aim of the market\nport is to abstract out\nall details of connecting to market data providers to receive real-time market events.
\nIt is therefore time we detail what those events consist of and what they mean. In\nshort, we need to describe the domain model the market port represents.\nThen, we will establish the features the port has to implement to represent it in\na useful way.
\nIf you are familiar with financial markets, simply skip down\nto port features.
Wikipedia offers the following definition:
\n\n\nA market is one of the many varieties of systems, institutions, procedures,\nsocial relations and infrastructures whereby parties engage in exchange.\n[…]\nIt can be said that a market is the process by which the prices of goods and\nservices are established.
\n
Said otherwise, a market is where sellers and buyers meet. Organized markets,\nor exchanges, define the rules and provide tools to facilitate the transactions,\nmost notably by gathering buyers and sellers intent and matching them.
\nIn its stricter acceptation in finance, a market is a notional place where\neconomical agents meet to trade two specific assets. For instance, the\n“Brent Crude market” allows trading oil from the North Sea against US dollar.\nAn exchange typically offers dozens or hundreds of markets.
An order is an expression of the intent of a buyer or seller. They come in\ntwo variants:
On top of that, the exchange may provide additional features, such as conditional\ntriggers (known as stop loss orders) and follow-up orders.
The match engine is the technical system responsible for gathering orders\nand matching them according to exchange rules. Whenever a match is found,\na transaction happens. That is, the matched orders fill each other, assets are\ntransferred between buyer and seller's accounts, and the orders are removed\nfrom the system.
The match engine organizes open orders into a list, known as the order book. It is\nsplit into a bid side (with buy orders) and an ask side (with sell orders).
The order book reflects the available liquidity on the market at any moment.\nThis information is usually public, though some exchanges offer the possibility\nof concealing orders for a fee.
As there is no authority quoting the price, it fluctuates naturally according\nto orders and transactions. We typically use three different prices to fully\ndefine the concept:
A tick represents the change of price from trade to trade. It is therefore a\nreal-time view of buyers and sellers consensus on price, and the most fundamental\nmovement in the market. On very active markets, there may be several thousands\nof ticks per second.
Ticks are the initial event Cryptomate has to respond to.
With time, many people devised ways to visualize and interpret market data,\naiming at anticipating future evolution for profit.
\nTechnical analysis is a discipline that studies past market data, in an attempt\nto forecast the direction of price. Without going into the details of this field,\nwe will highlight information that matters to Cryptomate.
\nAs price moves quickly, visualization systems were developed to build a more\nusable representation of its evolution over time. The most ubiquitous is the\ncandlestick chart. It synthesizes price moves over homogeneous time slices\nof configurable duration.
\n![\"Candlestick](\"/files/domain-candlestick-8b01defffe5d0dd1393135ddd55c8e8e.png\")
An alternate representation of the same data is bar-charts, that replace the\nshadow/body visual with tiny markers.
\nWhile this model is not the only one, it is the one normally used to store\nand communicate price history. Also, since it was prevalent for much of modern\nfinancial history, a lot of tools use that model to derive additional insight.\nFor instance, the vast majority of indicators (discrete mathematical formulas\nand algorithms to identify patterns) rely on this aggregated data.
\nOn the other hand, with tick data being increasingly available, and\nalgorithmic trading making it possible to interpret tick stream in a\nmeaningful way, newer indicators are now developing, that work directly\nwith raw ticks in an attempt to get a more accurate picture.
\nThe market port must therefore support both data streams, in order to\nbuild on the large amount of work done on classical indicators, while\nleveraging the newer tick based ones.
Having described the events and data the market port has to make available,\nwe can design it accordingly, revolving around two major themes:
\nThe aim of the market port is to abstract out all details of connecting to the market\nproviders and handling the real-time feeds. Using it should thus be as simple as handing\nit a feed description and a callback, getting an active subscription in return :
\n![\"Tick](\"/files/market-port-subscribe-5442ed3468a44bdc5c7cb924a2c3f8d3.png\")
The actual process will be a bit more complex, as the market engine will populate\naggregators with past data from a history adapter, if it has one.
\nReturned subscription should then be stored by the calling code, subsequently used to\naccess aggregated data and, eventually, cancel the subscription.
\nWhile the subscription is active, every update received from the market data feed\ngenerates an event, which is delivered to the supplied callback synchronously :
\n![\"Tick](\"/files/market-port-tickevent-f9cbbc49eda7dadabe42ec8fca6abc39.png\")
As event delivery is synchronous, the client object is responsible for choosing\nwhether to process events on the fly, or queue them for processing later, possibly\nin another thread.
\nFinally, order book events shall work in the same way, except the aggregator is replaced\nwith an order book view, aggregating order updates into a full view of current order book.
\nAssembling the features and objects described in previous sections, here is the full\nlist of interfaces that, together, constitute the market port:
\n| Name | \nDescription | \n
|---|---|
Aggregator | \nAggregated candle data over a configurable time period. | \n
Candle | \nAggregated tick data, forming a single candle. | \n
Engine | \nMain port entry point. | \n
FeedDescription | \nStatic data identifying a market on a provider and aggregation settings. | \n
Tick | \nSingle tick data. | \n
TickEventHandler | \nCallable that responds to tick events, provided by client code. | \n
TickSubscription | \nRepresents a subscription to tick events. | \n
OrderBook | \nInstant representation of the order book. | \n
OrderBookSubscription | \nRepresents a subscription to order book events. | \n
OrderBookEventHandler | \nCallable that responds to order book events, provided by client code. | \n
For detailed specification of each interface, check their definition and inline documentation\non GitHub. Note that due to the dynamic nature of python, not all interfaces need to\nappear as python types within the code.
\nThat is it for the market port. You will find the result on GitHub under the market\ndirectory. In the next post, we will turn to the trading port.