cbrown35/tradingsystem

1. Solution shape

- This is a multi-project .NET 8 solution centered on a trading platform, with clear separation between contracts, business logic, persistence, live trading, strategy research, and the host application.

- The main runtime host appears to be src/TradingSystem.Console, while the rest of the projects act as libraries plugged in through dependency injection.

2. Shared domain boundary: src/Common

- Common is the cross-cutting contract layer. It defines the core interfaces (ITradingService, IExchangeAdapter, IBacktester, IRiskManager, repositories, strategy interfaces) and the shared domain models (Order, Trade, MarketData, Signal, BacktestResult, RiskMetrics, etc.).

- This is the main architectural boundary: other projects implement these interfaces or consume these models, which keeps the trading logic decoupled from infrastructure and exchange specifics.

3. Application orchestration: src/Core

- Core contains coordination and monitoring-focused business logic.

- TradingSystemCoordinator is the likely top-level orchestrator for running trading workflows.

- The monitoring subtree is a substantial subsystem of its own: health checks, middleware, auth policy for protected health endpoints, notification/storage services, and a small UI/static asset layer under wwwroot.

4. Live trading runtime: src/RealTrading

- RealTrading contains the execution path for real or simulated trading.

- Important services include TradingService, RiskManager, RiskValidationService, MarketDataService, MarketDataCacheService, and adapters for different execution targets: SimulatedExchangeAdapter, TradovateAdapter, and TradingViewAdapter.

- PineScriptGenerator suggests the system can also generate TradingView-compatible strategy artifacts, which bridges strategy logic into external charting/execution tooling.

5. Strategy research and optimization: src/StrategySearch

- This project is the research/backtesting engine.

- It includes Backtester, TheoryGenerator, StrategyOptimizer, StrategySearchService, and a dedicated backtesting pipeline with metrics calculation, validation, parameter optimization, and trade execution simulation.

- The included strategies (SimpleMovingAverageStrategy, TheoryBasedStrategy) indicate this layer is where strategies are developed, scored, and tuned before being promoted to live trading.

6. Persistence and data access: src/Infrastructure

- Infrastructure owns the database boundary.

- It provides EF Core database contexts (TradingContext, DevelopmentTradingContext), a design-time factory, repository implementations for market data, orders, and trades, and DI wiring.

- Migrations include explicit TimescaleDB support, which signals that market/time-series data storage is a first-class concern rather than an afterthought.

7. Trading data flow

- The typical live flow is: market data enters through RealTrading services/adapters, is cached/validated, passed through strategy and risk logic, then executed via an exchange adapter.

- Orders and trades are persisted through repository interfaces into the infrastructure database layer.

- The same shared models are reused by backtesting and monitoring, so performance and health views operate on consistent domain objects.

8. Backtesting and optimization flow

- Historical market data is pulled from the persistence layer through repository abstractions.

- StrategySearch runs strategy logic against this data, computes metrics, validates outcomes, and searches parameter space for better configurations.

- The result is a feedback loop from research into live trading: strategies are evaluated offline before being used by the execution layer.

9. Observability and operational monitoring

- The repo includes a dedicated monitoring subsystem plus containerized observability assets.

- Prometheus configuration, alert rules, and templates are stored under prometheus/; Grafana dashboards and datasource provisioning live under grafana/.

- This means operational state is intended to be observed externally, with trading health and alerts integrated into metrics/alerting rather than only logs.

10. Application entrypoint and API surface

- TradingSystem.Console is not just a CLI shell; it contains controllers and a factory/service wiring layer, so it likely hosts an HTTP API as well.

- The README documents endpoints for placing orders, closing orders, listing open orders, fetching market data, and checking balances, which are the system’s primary external control surface.

11. Environment, deployment, and local operations

- Docker files and compose definitions indicate the system is designed to run in containers.

- Setup scripts initialize databases, TimescaleDB support, and secrets, while config/secrets.template.json and environment-specific appsettings files separate sensitive runtime configuration from code.

- The repo also implies supporting services like PostgreSQL and likely Redis for caching/operational state, with config driven setup rather than hardcoded endpoints.

12. Testing and documentation boundaries

- Tests are currently focused in tests/TradingSystem.Tests, which suggests API and integration coverage around the host/application surface.

- The docs/ and wiki/ trees are extensive and map directly to architecture, setup, backtesting, risk, and strategy guidance, which helps indicate that the codebase is organized around operational trading workflows rather than a single monolithic app.