# Monorepo Project Structure This diagram shows the monorepo structure with shared projects used by both API and Compute services. ```mermaid graph TD ROOT[Managing.sln
Monorepo Root] ROOT --> API[Managing.Api
API Server
Orleans] ROOT --> COMPUTE[Managing.Compute
Worker App
No Orleans] ROOT --> SHARED[Shared Projects] SHARED --> APP[Managing.Application
Business Logic] SHARED --> DOM[Managing.Domain
Domain Models] SHARED --> INFRA[Managing.Infrastructure
Database/External] SHARED --> COMMON[Managing.Common
Utilities] API --> APP API --> DOM API --> INFRA API --> COMMON COMPUTE --> APP COMPUTE --> DOM COMPUTE --> INFRA COMPUTE --> COMMON style ROOT fill:#9B59B6 style API fill:#4A90E2 style COMPUTE fill:#50C878 style SHARED fill:#FFD93D ``` ## Project Organization ### Root Level - **Managing.sln**: Solution file containing all projects ### Service Projects - **Managing.Api**: API Server with Orleans - Controllers, Orleans grains, HTTP endpoints - Handles user requests, creates jobs - **Managing.Compute**: Compute Worker App (NEW) - Background workers, job processors - No Orleans dependency - Dedicated CPU processing ### Shared Projects - **Managing.Application**: Business logic - `Backtester.cs`, `TradingBotBase.cs` - Used by both API and Compute - **Managing.Domain**: Domain models - `BundleBacktestRequest.cs`, `BacktestJob.cs` - Shared entities - **Managing.Infrastructure**: External integrations - Database repositories, InfluxDB client - Shared data access - **Managing.Common**: Utilities - Constants, enums, helpers - Shared across all projects ## Benefits 1. **Code Reuse**: Shared business logic between API and Compute 2. **Consistency**: Same domain models and logic 3. **Maintainability**: Single source of truth 4. **Type Safety**: Shared types prevent serialization issues 5. **Testing**: Shared test projects