borza.dev

• 24 June 2019
• C#, Architecture, Signals Network

Leveraging Hexagonal architecture in Signals Framework’s design

I created this technical article for Signals company in cooperation with their marketing team and the original post is published on Signals Tech Blog.
Signals is a platform where developers and professional traders can write their trading models in a cloud environment, using our own framework based in C#. Because the technological aspects of the platform are important for the user base, I wrote this article to clear out the design and used technologies.

Since we started developing Signals Platform, we have continued to dedicate extra focus to the core component used for defining your trading models — the Signals Framework. Our goal was to make the library so stable that a new version of the library would only need to be released when we extend the API with some features beneficial to clients. We knew we couldn’t force our traders to upgrade their framework version every time we improve the performance of some method or fix some bug. On the other hand, we also wanted the framework to be so flexible, that it would support various data streams and indicator combinations without modification of the library code itself. This article shows how we applied hexagonal architecture principles to solve the described challenges.

The key to achieving stability and flexibility was to make the Signals Framework library as lightweight as possible. In hexagonal architecture terms, the library basically represents the Signals Network’s domain with models like strategy, data series, market, exchange, currency pair, various types of orders, data marketplace and indicators marketplace. Regarding the domain logic, we have only added methods which are related to building automated trading strategies. There are functions for setting up the strategy data and indicators, registering callbacks executed on data stream updates, entering and exiting market positions, logging, etc. An important part of the domain is also strategy properties like actual market time, current positions and pending orders, which are used for making trading decisions.

You may wonder how we could claim that the library is lightweight when there are methods like EnterLongLimit or properties like Time in the strategy base class. Surely, there must be some code responsible for creating order and publishing it all the way to the UI, as well as some logic behind the Time property, which synchronizes strategy time with all the data streams. You are right, of course, but the actual code executing the logic lives outside of the Signals Framework library code base. In the library, we just depend on ports’ interfaces, as you can see in the code snippet below.

    public abstract class StrategyBase : IStrategy
    {
      private IEnumerable<Market> StrategyMarkets;
      private IStrategyTimeProvider StrategyTimeProvider;
      private IStrategyOrdersManager StrategyOrdersManager;
      private IStrategyLogger StrategyLogger;
    
      public DateTime Time => StrategyTimeProvider.CurrentTime;
      
      public abstract void Setup(DataMarketplace data, IndicatorsMarketplace indicators);
      
      public IOrder EnterLongLimit(double limitPrice, string label = null)
      {
        return StrategyOrdersManager
          .AddEntryPendingOrder(Market, StrategyPositionType.Long, 
                                limitPrice, OrderType.Limit, label);
      }
      
      ....
    }
    

Ports and adapters keep the domain functions inside Signals Framework really small, as they just contain code passing the parameters to the ports. This approach was suitable for methods which are already part of the Signals Framework API. But we needed a different solution to support various subscription models on top of data and indicators marketplaces. We didn’t want to release a new version of the Signals Framework library every time a new technical indicator or a new type of data stream is introduced to the marketplaces.

More importantly, we wanted to avoid dependency from the framework’s package to various data streams and indicators modules. On the contrary, we needed to reference the Signals Framework library from those packages, to use DataSeries, Markets, and other domain models. For that reason, we decided that each indicator and data stream will have its own library, containing its domain models definitions. When the user wants to use it, they must add a reference to the library in the strategy code editor.

In the following code, you can see a hypothetical implementation of a Google Trends data stream, which could be used for sentiment analysis on the given market. It contains definitions of GoogleTrend and GoogleTrendOptions domain models. There is also an implementation of DataMarketPlace extension method GoogleTrends(TimeSpan trendStartOffset, string currency), which provides a nice interface for strategy developer to specify the Google Trends stream in one marketPlace.GoogleTrends(5 years, “BTC”) API call.

using Signals.Framework;

public class GoogleTrend 
{
  public DateTime Timestamp { get; set; }
  public string Currency { get; set; }
  public double Interest { get; set; }
}

public class GoogleTrendOptions
{
  public TimeSpan TrendStartOffset { set; set; }
  public string Currency { get; set; }
}

//extension method so that we can define Google Trends stream as 
//market.GoogleTrends(TimeSpan.FromDays(365*5), "BTC") in strategy Setup method
public static class GoogleTrendsDataMarketPlaceExtension
{
  public static IDataSeries<GoogleTrend> GoogleTrends(this DataMarketPlace marketPlace, 
                                                      TimeSpan trendStartOffset,
                                                      string currency)
  {
    var options = new GoogleTrendOptions
    {
      TrendStartOffset = trendStartOffset,
      Currency = currency
    }
   
    return marketPlace.ConnectDataSeries<GoogleTrend, GoogleTrendOptions>(options);
  }
}

In the end, the architecture of Signals Framework toolkit has come to look like this.

As you can see, the Signals Framework assembly, data streams assemblies, and indicators assemblies do not depend on any infrastructure components. This keeps them lightweight, without dependencies on other packages, with just domain models code. The data stream drivers and adapters inside the Strategy Execution Service are the ones which cope with the infrastructure code and reference all the modules needed for messaging, database and API handling.

The main benefits of this design are:

• Upgrading is easy — we can release new versions of the Strategy Execution Service or data stream drivers with no worries about making changes which break the strategies’ code.
• Less space for bugs — as the packages referenced from the strategies are lightweight and contain almost no logic, there is not much space for coding errors and we don’t have to release new versions just for some bug fixes.
• Security — we don’t have to worry that someone can explore the logic and infrastructure details by decompiling the framework’s or data streams’ assemblies and reading the code, as they contain only models and methods accessible by the end user anyway.
• Stability — since the initial release of the Signals Platform, we are still using the same version of Signals Framework, data streams, and indicators assemblies. However, we performed numerous upgrades to the data stream drivers and Signals Framework’s adapters implementations. This way, the end users benefit from improved performance and removed bugs, without any action needed from their side.