Arquitetura do Backend¶

O backend do TepConfina e construido com .NET 10 seguindo Clean Architecture. A solucao e composta por quatro projetos organizados em camadas com dependencias unidirecionais.

Estrutura da Solution¶

TepConfina/
├── src/
│   ├── TepConfina.Domain/
│   │   ├── Entities/          # 16 entidades de dominio
│   │   ├── Enums/             # Enumeracoes de negocio
│   │   └── Interfaces/        # Contratos de repositorio
│   │
│   ├── TepConfina.Application/
│   │   ├── Services/          # 18+ servicos de negocio
│   │   ├── DTOs/              # Objetos de transferencia
│   │   ├── Interfaces/        # Contratos de servico
│   │   └── Validators/        # Regras de validacao
│   │
│   ├── TepConfina.Infrastructure/
│   │   ├── Data/
│   │   │   ├── AppDbContext.cs       # DbContext principal
│   │   │   └── Configurations/      # Fluent API configs
│   │   ├── Repositories/            # Implementacoes
│   │   └── Cache/                   # Redis cache service
│   │
│   └── TepConfina.API/
│       ├── Controllers/       # 17 controllers REST
│       ├── Middleware/         # Pipeline customizado
│       ├── Extensions/        # DependencyInjection.cs
│       └── Program.cs         # Entry point e pipeline
│
└── tests/
    ├── TepConfina.UnitTests/
    └── TepConfina.IntegrationTests/

Camada Domain¶

O nucleo do sistema contem as 16 entidades de dominio, sem dependencias externas.

Camada Application¶

Contem a logica de negocio encapsulada em 18+ servicos, cada um com sua interface correspondente.

graph LR
    CTRL[Controller] --> ISVC[IService]
    ISVC -.->|DI| SVC[Service]
    SVC --> IREPO[IRepository]
    IREPO -.->|DI| REPO[Repository]
    SVC --> DTO[DTO]

Os servicos realizam:

• Validacao de regras de negocio
• Mapeamento manual entre entidades e DTOs
• Calculo de KPIs (GMD, custo/arroba, resultado financeiro)
• Orquestracao de operacoes entre repositorios

Camada Infrastructure¶

Implementa os contratos definidos nas camadas internas.

DbContext¶

O AppDbContext configura:

• Global query filters para IsDeleted e TenantId
• Fluent API para mapeamento de entidades
• Interceptors para auditoria automatica (CreatedAt, UpdatedAt)

Repositorios¶

Redis Cache¶

O cache Redis e utilizado para:

• Cotacoes de mercado (TTL: 15 minutos)
• Dados de dashboard (TTL: 5 minutos)
• Sessoes de refresh token

Camada API¶

Controllers¶

Os 17 controllers seguem o padrao RESTful com versionamento via URL (/api/v1/).

Pipeline de Middleware¶

A ordem dos middlewares no Program.cs e critica para o funcionamento correto:

graph TD
    REQ[Request] --> S1[1. Serilog Request Logging]
    S1 --> S2[2. Security Headers]
    S2 --> S3[3. CORS]
    S3 --> S4[4. Authentication]
    S4 --> S5[5. Authorization]
    S5 --> S6[6. Rate Limiting]
    S6 --> S7[7. Business Metrics Middleware]
    S7 --> S8[8. Controllers]
    S8 --> RES[Response]

    style REQ fill:#0277BD,color:#fff
    style RES fill:#2E7D32,color:#fff

Registro de Dependencias¶

Toda a configuracao de DI esta centralizada no metodo de extensao AddTepConfinaServices() em DependencyInjection.cs:

public static class DependencyInjection
{
    public static IServiceCollection AddTepConfinaServices(
        this IServiceCollection services,
        IConfiguration configuration)
    {
        // Infrastructure
        services.AddDbContext<AppDbContext>(...);
        services.AddStackExchangeRedisCache(...);

        // Repositories
        services.AddScoped(typeof(IRepository<>), typeof(Repository<>));
        services.AddScoped<ILoteRepository, LoteRepository>();

        // Services
        services.AddScoped<IAuthService, AuthService>();
        services.AddScoped<ILoteService, LoteService>();
        // ... demais servicos

        return services;
    }
}

Pipeline de Market Data¶

A ingestão de cotações usa o padrão Provider + Background Hosted Service, com abstração IMarketDataProvider para troca a quente entre fornecedores.

Componentes¶

Fluxo¶

graph LR
    TV[TradingView WebSocket] -->|@mathieuc/tradingview| SIDECAR[tv-scraper Node :3001]
    SIDECAR -->|HTTP /candles /quote| PROVIDER[TradingViewMarketDataProvider]
    PROVIDER --> INGEST[MarketIngestionHostedService 5min]
    INGEST --> REPO[MarketRepository]
    REPO --> DB[(MarketCandles + MarketQuotes + PrecosMercado)]
    DB --> QUERY[MarketQueryService]
    QUERY --> CTRL[MarketController]

Sidecar tv-scraper (Node.js)¶

Localizado em scrapers/tv/, roda como segundo container na task ECS da API (essential=false).

• Imagem: public.ecr.aws/docker/library/node:20-alpine (mirror ECR Public para evitar rate-limit Docker Hub)
• Endpoints expostos: /health, /quote?symbol=..., /candles?symbol=...&timeframe=...&limit=...
• Comunicação API → sidecar: http://localhost:3001 (network mode awsvpc compartilha interface)
• Healthcheck: wget /health a cada 30s
• Build: mesmo CodePipeline da API; buildspec.yml builda 2 imagens e atualiza task def com ambos containers

Configuração¶

"MarketData": {
  "Provider": "tradingview",          // tradingview | brapi | stonex | mock
  "SyncIntervalSeconds": 300,
  "ActiveContracts": [ "BGI1!" ],     // contratos puxados a cada ciclo
  "TradingView": {
    "SidecarUrl": "http://localhost:3001"
  },
  "Brapi": {
    "ApiBaseUrl": "https://brapi.dev",
    "ApiToken": ""                    // do Secrets Manager
  }
}

A troca de provider é zero-downtime: edita env var MarketData__Provider na task def e força novo deployment.

Health Checks¶

O sistema expoe dois endpoints de health check:

Observabilidade¶

O backend integra OpenTelemetry para traces e metricas:

• Traces: Requisicoes HTTP, queries EF Core, chamadas Redis
• Metricas: Contadores de requisicao, latencia, erros por endpoint
• Logs: Serilog estruturado com enrichers de correlacao

Paginas relacionadas: Visao Geral | Frontend | Mobile