Infrastructure Overview

The Infrastructure Layer fulfills the abstract interfaces defined by the Application tier by mapping them outwards to rigid physical realities. While the Domain and Application define what happens, the Infrastructure layer defines how it happens (e.g., executing SQL statements, sending HTTP requests to LLMs or Python services, managing encryption primitives, or emitting SignalR events).

Business Logic Intent

The core intent of the Infrastructure tier in MILTON is strict encapsulation of external concerns:

• Persistence: Ensuring that Entity Framework maps correctly to the underlying PostgreSQL engine, with seamless integration of Row-Level Security via Tenant interception.
• Security: Abstracting DPAPI-based encryption (DataProtectionEncryptionService) so that API keys and repository tokens are stored securely in the database but remain utterly transparent to the business domain.
• External Integration: Providing physical implementations for complex outbound processes like clustering code via Python (ClusteringService), orchestrating Gotenberg for PDF generation, sending notification state updates over Wolverine, and interacting with the core AI platform via IAIService.

Architecture & Boundaries

The infrastructure components heavily rely on Aspire orchestration for service discovery. Components like the ClusteringService or PDF renderers use named HttpClient registrations bound to Aspire service definitions rather than hardcoded URLs.

Additionally, this layer enforces the “Message-Only” pipeline model for realtime updates. Rather than the API pushing SignalR messages directly to the client, the WolverineUserNotifier translates abstract API notifications into strongly typed RabbitMQ events. These are consumed by the decoupled MILTON.NotificationService, preventing the primary API from becoming bogged down maintaining thousands of long-lived WebSockets.

Mermaid Component Diagram

graph TD
    subgraph MILTON API (Application Core)
        API[Feature Endpoints & Handlers]
        AppInterfaces[Application Interfaces]
    end

    subgraph Infrastructure Tier
        AppInterfaces -.-> |implemented by| DB[Persistence (AppDbContext)]
        AppInterfaces -.-> |implemented by| SEC[Security (DPAPI)]
        AppInterfaces -.-> |implemented by| AI[AI Integration]
        AppInterfaces -.-> |implemented by| CLUS[Clustering Service]
        AppInterfaces -.-> |implemented by| NOTIFY[Notifications (Wolverine)]
        AppInterfaces -.-> |implemented by| EXP[Export / Rendering]
    end
    
    DB --> |Entity Framework| Postgres[(PostgreSQL milton-db)]
    AI --> |HTTP| LLMProviders((OpenAI / Custom LLMs))
    CLUS --> |HTTP| Python(Python Clustering)
    NOTIFY --> |Message| Rabbit(RabbitMQ Bus)
    EXP --> |HTTP| Gotenberg(Gotenberg PDF)

Modules and Components

• AI: Physical adapters for LLM interactions.
• Clustering: HTTP Client adapter leveraging Aspire service discovery to interact with the Python analysis service.
• Export & PDF: Bridging Markdown abstractions to rendered HTML/PDF via Gotenberg pipelines.
• Notifications: Core abstractions mapping system state changes into Wolverine messages for the SignalR notification hub. Includes WolverineUserNotifier.
• Persistence: Hosts the core AppDbContext, AppDbContextFactory, and critical DbInterceptors (e.g., Tenant configuration for Row-Level Security).
• Security: Implementation of data protection, AES backups, and definition of MiltonPermissions used in RBAC.
• Storage: Abstractions over the S3-based shared storage and claim-check systems.