229 lines
6.3 KiB
Markdown
229 lines
6.3 KiB
Markdown
# Orchestrator Architecture Streamlining Plan
|
|
|
|
## Current State Analysis
|
|
|
|
### Basic TradingOrchestrator (`core/orchestrator.py`)
|
|
- **Size**: 880 lines
|
|
- **Purpose**: Core trading decisions, model coordination
|
|
- **Features**:
|
|
- Model registry and weight management
|
|
- CNN and RL prediction combination
|
|
- Decision callbacks
|
|
- Performance tracking
|
|
- Basic RL state building
|
|
|
|
### Enhanced TradingOrchestrator (`core/enhanced_orchestrator.py`)
|
|
- **Size**: 5,743 lines (6.5x larger!)
|
|
- **Inherits from**: TradingOrchestrator
|
|
- **Additional Features**:
|
|
- Universal Data Adapter (5 timeseries)
|
|
- COB Integration
|
|
- Neural Decision Fusion
|
|
- Multi-timeframe analysis
|
|
- Market regime detection
|
|
- Sensitivity learning
|
|
- Pivot point analysis
|
|
- Extrema detection
|
|
- Context data management
|
|
- Williams market structure
|
|
- Microstructure analysis
|
|
- Order flow analysis
|
|
- Cross-asset correlation
|
|
- PnL-aware features
|
|
- Trade flow features
|
|
- Market impact estimation
|
|
- Retrospective CNN training
|
|
- Cold start predictions
|
|
|
|
## Problems Identified
|
|
|
|
### 1. **Massive Feature Bloat**
|
|
- Enhanced orchestrator has become a "god object" with too many responsibilities
|
|
- Single class doing: trading, analysis, training, data processing, market structure, etc.
|
|
- Violates Single Responsibility Principle
|
|
|
|
### 2. **Code Duplication**
|
|
- Many features reimplemented instead of extending base functionality
|
|
- Similar RL state building in both classes
|
|
- Overlapping market analysis
|
|
|
|
### 3. **Maintenance Nightmare**
|
|
- 5,743 lines in single file is unmaintainable
|
|
- Complex interdependencies
|
|
- Hard to test individual components
|
|
- Performance issues due to size
|
|
|
|
### 4. **Resource Inefficiency**
|
|
- Loading entire enhanced orchestrator even if only basic features needed
|
|
- Memory overhead from unused features
|
|
- Slower initialization
|
|
|
|
## Proposed Solution: Modular Architecture
|
|
|
|
### 1. **Keep Streamlined Base Orchestrator**
|
|
```
|
|
TradingOrchestrator (core/orchestrator.py)
|
|
├── Basic decision making
|
|
├── Model coordination
|
|
├── Performance tracking
|
|
└── Core RL state building
|
|
```
|
|
|
|
### 2. **Create Modular Extensions**
|
|
```
|
|
core/
|
|
├── orchestrator.py (Basic - 880 lines)
|
|
├── modules/
|
|
│ ├── cob_module.py # COB integration
|
|
│ ├── market_analysis_module.py # Market regime, volatility
|
|
│ ├── multi_timeframe_module.py # Multi-TF analysis
|
|
│ ├── neural_fusion_module.py # Neural decision fusion
|
|
│ ├── pivot_analysis_module.py # Williams/pivot points
|
|
│ ├── extrema_module.py # Extrema detection
|
|
│ ├── microstructure_module.py # Order flow analysis
|
|
│ ├── correlation_module.py # Cross-asset correlation
|
|
│ └── training_module.py # Advanced training features
|
|
```
|
|
|
|
### 3. **Configurable Enhanced Orchestrator**
|
|
```python
|
|
class ConfigurableOrchestrator(TradingOrchestrator):
|
|
def __init__(self, data_provider, modules=None):
|
|
super().__init__(data_provider)
|
|
self.modules = {}
|
|
|
|
# Load only requested modules
|
|
if modules:
|
|
for module_name in modules:
|
|
self.load_module(module_name)
|
|
|
|
def load_module(self, module_name):
|
|
# Dynamically load and initialize module
|
|
pass
|
|
```
|
|
|
|
### 4. **Module Interface**
|
|
```python
|
|
class OrchestratorModule:
|
|
def __init__(self, orchestrator):
|
|
self.orchestrator = orchestrator
|
|
|
|
def initialize(self):
|
|
pass
|
|
|
|
def get_features(self, symbol):
|
|
pass
|
|
|
|
def get_predictions(self, symbol):
|
|
pass
|
|
```
|
|
|
|
## Implementation Plan
|
|
|
|
### Phase 1: Extract Core Modules (Week 1)
|
|
1. Extract COB integration to `cob_module.py`
|
|
2. Extract market analysis to `market_analysis_module.py`
|
|
3. Extract neural fusion to `neural_fusion_module.py`
|
|
4. Test basic functionality
|
|
|
|
### Phase 2: Refactor Enhanced Features (Week 2)
|
|
1. Move pivot analysis to `pivot_analysis_module.py`
|
|
2. Move extrema detection to `extrema_module.py`
|
|
3. Move microstructure analysis to `microstructure_module.py`
|
|
4. Update imports and dependencies
|
|
|
|
### Phase 3: Create Configurable System (Week 3)
|
|
1. Implement `ConfigurableOrchestrator`
|
|
2. Create module loading system
|
|
3. Add configuration file support
|
|
4. Test different module combinations
|
|
|
|
### Phase 4: Clean Dashboard Integration (Week 4)
|
|
1. Update dashboard to work with both Basic and Configurable
|
|
2. Add module status display
|
|
3. Dynamic feature enabling/disabling
|
|
4. Performance optimization
|
|
|
|
## Benefits
|
|
|
|
### 1. **Maintainability**
|
|
- Each module ~200-400 lines (manageable)
|
|
- Clear separation of concerns
|
|
- Individual module testing
|
|
- Easier debugging
|
|
|
|
### 2. **Performance**
|
|
- Load only needed features
|
|
- Reduced memory footprint
|
|
- Faster initialization
|
|
- Better resource utilization
|
|
|
|
### 3. **Flexibility**
|
|
- Mix and match features
|
|
- Easy to add new modules
|
|
- Configuration-driven setup
|
|
- Development environment vs production
|
|
|
|
### 4. **Development**
|
|
- Teams can work on individual modules
|
|
- Clear interfaces reduce conflicts
|
|
- Easier to add new features
|
|
- Better code reuse
|
|
|
|
## Configuration Examples
|
|
|
|
### Minimal Setup (Basic Trading)
|
|
```yaml
|
|
orchestrator:
|
|
type: basic
|
|
modules: []
|
|
```
|
|
|
|
### Full Enhanced Setup
|
|
```yaml
|
|
orchestrator:
|
|
type: configurable
|
|
modules:
|
|
- cob_module
|
|
- neural_fusion_module
|
|
- market_analysis_module
|
|
- pivot_analysis_module
|
|
```
|
|
|
|
### Custom Setup (Research)
|
|
```yaml
|
|
orchestrator:
|
|
type: configurable
|
|
modules:
|
|
- market_analysis_module
|
|
- extrema_module
|
|
- training_module
|
|
```
|
|
|
|
## Migration Strategy
|
|
|
|
### 1. **Backward Compatibility**
|
|
- Keep current Enhanced orchestrator as deprecated
|
|
- Gradually migrate features to modules
|
|
- Provide compatibility layer
|
|
|
|
### 2. **Gradual Migration**
|
|
- Start with dashboard using Basic orchestrator
|
|
- Add modules one by one
|
|
- Test each integration
|
|
|
|
### 3. **Performance Testing**
|
|
- Compare Basic vs Enhanced vs Modular
|
|
- Memory usage analysis
|
|
- Initialization time comparison
|
|
- Decision-making speed tests
|
|
|
|
## Success Metrics
|
|
|
|
1. **Code Size**: Enhanced orchestrator < 1,000 lines
|
|
2. **Memory**: 50% reduction in memory usage for basic setup
|
|
3. **Speed**: 3x faster initialization for basic setup
|
|
4. **Maintainability**: Each module < 500 lines
|
|
5. **Testing**: 90%+ test coverage per module
|
|
|
|
This plan will transform the current monolithic enhanced orchestrator into a clean, modular, maintainable system while preserving all functionality and improving performance. |