62 lines
2.2 KiB
Markdown
62 lines
2.2 KiB
Markdown
# Stock Bot Project Structure Refactoring
|
|
|
|
This document outlines the changes made to improve separation of concerns in the stock-bot project architecture.
|
|
|
|
## Directory Structure Changes
|
|
|
|
1. Created a dedicated `libs/` directory (replacing the previous `packages/` approach)
|
|
2. Split monolithic type definitions into domain-specific modules
|
|
3. Created specialized libraries for cross-cutting concerns
|
|
|
|
## New Libraries
|
|
|
|
### 1. `@stock-bot/types`
|
|
Domain-specific type definitions organized by functional area:
|
|
- `market/` - Market data structures (OHLCV, OrderBook, etc.)
|
|
- `trading/` - Trading types (Orders, Positions, etc.)
|
|
- `strategy/` - Strategy and signal types
|
|
- `events/` - Event definitions for the event bus
|
|
- `api/` - Common API request/response types
|
|
- `config/` - Configuration type definitions
|
|
|
|
### 2. `@stock-bot/event-bus`
|
|
A Redis-based event bus implementation for inter-service communication:
|
|
- Publish/subscribe pattern for asynchronous messaging
|
|
- Support for typed events
|
|
- Reliable message delivery
|
|
|
|
### 3. `@stock-bot/utils`
|
|
Common utility functions shared across services:
|
|
- `dateUtils` - Date/time helpers for market data
|
|
- `financialUtils` - Financial calculations (Sharpe ratio, drawdown)
|
|
- `logger` - Standardized logging service
|
|
|
|
### 4. `@stock-bot/api-client`
|
|
Type-safe API clients for inter-service communication:
|
|
- `BaseApiClient` - Common HTTP client functionality
|
|
- Service-specific clients (BacktestClient, StrategyClient)
|
|
|
|
## Benefits of the New Architecture
|
|
|
|
1. **Better Separation of Concerns**
|
|
- Each library has a clear, focused purpose
|
|
- Domain types are logically grouped
|
|
|
|
2. **Improved Maintainability**
|
|
- Smaller, focused modules
|
|
- Clear dependencies between modules
|
|
|
|
3. **Type Safety**
|
|
- Consistent types across the entire system
|
|
- Better IDE autocompletion and error checking
|
|
|
|
4. **Reduced Duplication**
|
|
- Shared utilities in a central location
|
|
- Consistent implementation of common patterns
|
|
|
|
## Next Steps
|
|
|
|
1. Update service implementations to use the new libraries
|
|
2. Migrate from the old packages directory to the new libs structure
|
|
3. Implement domain-specific validations in each type module
|
|
4. Add unit tests for each library
|