Привет всем! В предыдущий раз я описал, как стратегии выставляют заявки. Сегодня будет ещё более интересная тема: получение маркет-даты. Для упрощения, под маркет-датой, буду иметь в виду тиковые данные (время, цена, объём).

     Я уже рассказывал про классы стратегий,  про то, что они используют интерфейс, который отвечает за получение маркет-даты – IMarketDataGate. Внутри себя, стратегии подписываются на событие AddTick из IMarketDataGate – т.е. на каждый тик стратегия проводит свой анализ данных, расчеты, и, при определённых условиях, выставляет заявки. Стратегии не важно, как генерируются тики – она просто реагирует на это событие. IMarketDataGate, имеет два варианта реализации. Первый – это обёрткой над COM библиотекой брокера (в моём случае – смартком). Тут всё просто – каждый день, кроме праздников и выходных, с 10 часов, магическим образом, начинают литься тики – их мне посылает система брокера. А вот для организации локальных бэктестов, нужен какой-то иной источник данных – некая имитация брокера по части генерации тиков. И тут-то и появляется наш герой – ITickGenerator.

interface ITickGenerator
{
   event EventHandler<StockTickEventArgs> OnTick;
   event Action OnEnd;
   void Start(string symbol);
}

     Добрый день. В предыдущем посте были описаны базовые компоненты – классы обёртки над API брокера. Не хотелось нагружать их дополнительной логикой, поэтому оставим их как есть, и перейдём к чуть более сложному объекту. На сцене появляется IOrderManager, который отвечает за заявки и сделки по ним.

interface IOrderManager
{
   List<Order> GetOrders(string symbol, int strategyID);
   void PlaceOrder(string symbol, int strategyID, OrderAction action, OrderType type, double price, double amount, double stopPrice);
} 

     Всего два метода – выставить заявку и получить их список. Но, у реализации IOrderManager’а непростая задача – надо не просто выставлять заявки, но также хранить какая стратегия это сделала и какие прошли сделки. Получается, у OrderManager’а есть некое состояние – список заявок/сделок, поэтому этот объект относится больше к модели, чем к сервисному слою программы. Перед этим я описывал IPortfolioGate – класс-обёртка для работы с портфелем, вот у него нет состояния, он просто транслирует вызов методов внешней COM библиотеки, а вот OrderManager это некий дополнительный уровень над всем этим – у него появляются «знания» о предметной области, и именно он используется в классах стратегий.
     Также, появляются две сущности – заявка (Order) и сделка (Trade). Класс Order имеет список сделок прошедших по данной заявке.

class Order
{
   public string Symbol { get; set; }
   public OrderAction Action { get; set; }
   public double Price { get; set; }
   …
   public List<Trade> Trades { get; set; }
}

     Приветствую! В предыдущем посте была теория, теперь к делу. Кое-что буду упрощать, чтобы представить картинку в целом.

     Итак, чтобы проект не зависел от API внешней com библиотеки (SmartCom или д.р.), чтобы в коде стратегий  не использовались специфические типы, разработку я начала с обёрток над смарткомом. Я определил три базовых интерфейса: IConnectGate, IMarketDataGate и IPortfolioGate. Соответственно для подключения, для получения маркет-даты и для выставления заявок и работы с портфелем. Причём каждый из этих трёх интерфейсов мне надо было реализовать минимум дважды – для смарткома и для локального тестера.

     В случае со смарткомом, это некий адаптер-обёртка, благодаря которому, я оперирую собственными типами и не завишу от com библиотеки. Т.е. у меня есть свои типы (например, направление заявки, тайм-фрейм), которые используются в коде, а адаптер-обёртка конвертирует их в специфические, понятные внешней библиотеке. Также, желательно, чтобы у каждого объекта, в программе, была только одна обязанность, поэтому никакой дополнительной логики эти обёртки не несут.

   Добрый день. В предыдущем посте я вкратце описал предпосылки и суть системы. Сегодня будет немного теории,  я думал не вставлять эту часть, но описанные здесь термины будут использоваться в последующих статьях.

   Даже такие проекты, как торговая система, требуют определённого подхода к структуре – проект разрастается со временем, хочется большего, и на это надо закладываться в самом начале. Даже, если система пишется под себя, не стоит уклоняться от  более формального подхода. Это, как ставить кубик на кубик — хорошая расстановка даст более прочную башню. Такие проекты справляются с увеличением сложности, новые изменения усиливают проект, в конце концов, такие проекты, способны перерасти во что-то более сложное (типа фазового перехода). А проекты с непродуманной архитектурой наоборот – со временем вносить изменения становится мучительнее и дороже, возрастают затраты на обслуживание, новые изменения ослабляют проект и он не способен перерасти во что-то более сложное. Но, сами понимаете, не всё так просто. Выбирая, каким будет проект, мы, опираясь на опыт, всё равно, угадываем направления развития.

Привет всем! Хотел опубликовать серию постов с описанием, как я на C# разработал систему для тестирования и торговли. Уклон будет больше в программирование, но в рамках алго.

Смысл в том, что я старался придерживаться правил ООП и сделать систему простой и конфигурируемой. В нескольких статьях я простыми словами расскажу про фишечки программирования, которые использовал. Расскажу про подходы к написанию объектно-ориентированного кода и про соответствующие библиотеки, которые использовал. Уделю внимание базам данных, как можно связываться с базами посредством объектно-реляционных преобразований  и про сам SQL. Опишу, что такое внедрение зависимостей и IoC контейнер, и как благодаря этому, только от одной переменной зависит режим работы – тестовый или торговый. Приведу пример реализации стратегии в рамках системы.
Оговорюсь, что это не hft – здесь не будет специальной оптимизации, работы с драйверами, памятью и т.д. В разработке использовал SmartCom и открытые библиотеки на C#. Чтобы не получилось слишком объёмно – буду сокращать, и опишу только часть моментов, опустив остальное (многопоточнось, проверки, защиту от сбоев и т.д.) Знаю, что есть StockSharp и пр. но… но… у меня с этим не пошло… мне проще оказалось сделать самому, чем от кого-то зависеть.

Оговорюсь так же, что всё нижесказанное – это моё личное мнение, сформированное в рамках моего понимания, не претендующее ни на что.  Я всё буду объяснять своими словами, и лишь хочу осветить тот материал, который здесь не обсуждался, либо обсуждался мало. В своё время, смарт-лаб очень много дал мне, что бы не говорили, это очень хороший ресурс, где много интересных людей! Я хочу внести и свою лепту в копилку, может кому-то, когда-нибудь пригодиться. Буду публиковать по одной – две статьи в неделю, всего будет 11 статей.