Principle:Nautechsystems Nautilus trader Importable Strategy Configuration
| Field | Value |
|---|---|
| sources | https://github.com/nautechsystems/nautilus_trader, https://nautilustrader.io/docs/ |
| domains | strategy-management, configuration-management, factory-pattern |
| last_updated | 2026-02-10 12:00 GMT |
Overview
An Importable Strategy Configuration defines a declarative specification for instantiating a trading strategy from its fully qualified class path and a serializable configuration dictionary, enabling factory-based strategy creation without direct class imports.
Description
In a configuration-driven backtesting or live trading system, strategies must be instantiated from configuration files, databases, or remote orchestration payloads -- contexts where direct Python import statements are unavailable or undesirable. The Importable Strategy Configuration principle addresses this by defining a schema that contains:
- A strategy class path -- the fully qualified Python path (module and class name) of the strategy to instantiate.
- A config class path -- the fully qualified Python path of the strategy's configuration class.
- A configuration dictionary -- the raw parameters that will be deserialized into the configuration class.
This three-part specification enables a factory pattern where a generic factory function can:
- Dynamically resolve (import) the strategy class from its path.
- Dynamically resolve the configuration class from its path.
- Deserialize the configuration dictionary into a typed configuration object.
- Instantiate the strategy by passing the deserialized configuration.
The principle solves several important problems:
- Decoupling -- Strategy selection is decoupled from the code that orchestrates backtests or live systems. The orchestrator does not need to import every possible strategy class.
- Serialization -- The entire strategy specification can be serialized to JSON, YAML, or any other format, making it suitable for configuration files, APIs, and message queues.
- Dynamic composition -- Multiple strategies can be composed at runtime by listing multiple importable configurations, enabling scenario-based backtesting.
- Type safety -- The configuration dictionary is deserialized into a typed configuration object (not passed as raw kwargs), ensuring validation at construction time.
Usage
Use the Importable Strategy Configuration principle whenever you need to:
- Instantiate strategies from configuration files or external data sources.
- Build configuration-driven backtest scenarios where strategies are selected at runtime.
- Serialize strategy definitions for storage, transfer, or version control.
- Compose multiple strategies in a single trading system without hardcoding imports.
- Enable a factory or plugin architecture for strategy instantiation.
Theoretical Basis
The Importable Strategy Configuration follows the Abstract Factory and Service Locator patterns, combined with late binding (dynamic import resolution).
Pseudocode for factory-based strategy instantiation:
ImportableStrategyConfig:
strategy_path : string # e.g., "mypackage.strategies:MyStrategy"
config_path : string # e.g., "mypackage.strategies:MyStrategyConfig"
config : dict[str, Any] # Raw configuration parameters
StrategyFactory.create(importable_config):
# Step 1: Resolve classes from paths
strategy_cls = dynamic_import(importable_config.strategy_path)
config_cls = dynamic_import(importable_config.config_path)
# Step 2: Deserialize raw dict into typed config
typed_config = config_cls.from_dict(importable_config.config)
# Step 3: Instantiate strategy with typed config
RETURN strategy_cls(config=typed_config)
Key design constraints:
INVARIANTS:
1. strategy_path MUST resolve to a class that accepts a `config` keyword argument.
2. config_path MUST resolve to a configuration class that can be deserialized from a dict.
3. The config dict MUST contain all required fields of config_cls.
4. The factory MUST NOT require prior knowledge of available strategy classes.
The pattern decouples the specification of a strategy (data) from its instantiation (behavior), which is essential for systems where the set of available strategies is open-ended and may be extended by users.