C4-Modell

Kontext-, Container-, Deployment-, Komponenten- und Code-Ansichten von MyBotBox.

Das C4-Modell beschreibt ein System auf vier Zoomebenen — Kontext → Container → Komponente → Code — sowie einer Deployment-Ansicht. Jede Ebene fügt Details hinzu, ohne den Faden zur übergeordneten Ebene zu verlieren.

Ebene 1 — Systemkontext

Wer MyBotBox verwendet und womit es kommuniziert.

flowchart TB
    Builder([Builder<br/>designs & runs workflows])
    Admin([Org Admin<br/>members · permissions · billing])
    MBB[["MyBotBox<br/>visual AI workflow platform"]]
    Firebase[Firebase<br/>auth + realtime]
    LLM[LLM Providers<br/>17 adapters]
    Integrations[90+ Integrations<br/>Slack · Gmail · GitHub · …]
    Stripe[Stripe<br/>subscriptions + usage]

    Builder --> MBB
    Admin --> MBB
    MBB --> Firebase
    MBB --> LLM
    MBB --> Integrations
    MBB --> Stripe

Ebene 2 — Container

Die deploybare Einheiten, aus denen die Plattform besteht.

flowchart TB
    User([Builder])
    Edge[Route 53 → Firebase Hosting<br/>edge rewrite]

    subgraph CR ["Cloud Run — Next.js"]
        Web[Web App<br/>editor · dashboard · SSR]
        API[API Routes<br/>workflows · auth · billing]
        Exec[Executor<br/>DAG + 30 handlers]
    end

    Tasks[Cloud Tasks + 6 Functions<br/>async + polling]
    PG[(Cloud SQL<br/>PostgreSQL 17 + pgvector)]
    Redis[(Memorystore Redis<br/>rate-limit + cache)]
    GCS[(Cloud Storage)]
    Auth[Firebase Auth]
    FS[(Firestore<br/>realtime collab)]

    User --> Edge --> Web
    Web --> API
    API --> Exec
    API --> Tasks --> Exec
    API --> PG
    Exec --> PG
    API --> Redis
    API --> GCS
    Web --> Auth
    Web --> FS

Deployment — Google Cloud

Wo die Container ausgeführt werden. Staging und Produktion sind separate GCP-Projekte; Firebase Hosting ist jedem Cloud-Run-Dienst vorgeschaltet.

flowchart TB
    User([User browser])
    DNS[AWS Route 53]
    FH[Firebase Hosting<br/>__session cookie only]

    subgraph STG ["Staging · ystudio-core · us-central1"]
        SRUN[Cloud Run: mybotbox-app<br/>min 1 · 80 concurrency]
        SVPC[VPC connector]
        SREDIS[(Memorystore Redis 7)]
        SSQL[(Cloud SQL · PostgreSQL 17)]
        STASK[Cloud Tasks + 6 Functions]
        SSEC[Secret Manager]
        SGCS[(Cloud Storage)]
    end

    subgraph PRD ["Production · mybotbox-prod · us-central1"]
        PRUN[Cloud Run: mybotbox-app]
        PSQL[(Cloud SQL · mybotbox-db)]
    end

    User --> DNS --> FH
    FH --> SRUN
    FH --> PRUN
    SRUN --> SVPC --> SREDIS
    SRUN --> SSQL
    SRUN --> STASK --> SRUN
    SRUN --> SSEC
    SRUN --> SGCS
    PRUN --> PSQL

Ebene 3 — Komponenten (Request-Sicherheitspipeline)

Jede API-Anfrage durchläuft dieselben wiederverwendbaren Prüfpunkte, bevor eine Geschäftslogik ausgeführt wird. Siehe Request-Pipeline für die vollständige Beschreibung.

flowchart LR
    Caller([Caller]) --> MW[Middleware<br/>session · CSP]
    MW --> Guards[API Guards<br/>auth + workspace access]
    Guards --> Authn[Auth<br/>Firebase verify]
    Guards --> RBAC[RBAC<br/>entity-scoped grant]
    Guards --> RL[Rate Limiter<br/>sliding window]
    Guards --> Handler[Route Handler<br/>Zod-validated]
    Handler --> Exec[Executor]

Ebene 4 — Code (die zwei Verträge)

Die unterste Ebene: die Typverträge, in die sich alles einklinkt. Jeder externe Dienst ist ein Port mit austauschbaren Adaptern, die je nach Umgebung gewählt werden; jeder Block ist ein Handler hinter einer einzigen Schnittstelle, an die der Executor delegiert.

classDiagram
    direction LR

    class EmailProvider {
        <<port>>
        +send(message) Result
    }
    class SendgridAdapter
    class ResendAdapter
    class AzureAdapter
    EmailProvider <|.. SendgridAdapter
    EmailProvider <|.. ResendAdapter
    EmailProvider <|.. AzureAdapter

    class BlockHandler {
        <<port>>
        +canHandle(block) bool
        +execute(ctx, block) BlockOutput
    }
    class AgentHandler
    class FunctionHandler
    class ApiHandler
    class RouterHandler
    BlockHandler <|.. AgentHandler
    BlockHandler <|.. FunctionHandler
    BlockHandler <|.. ApiHandler
    BlockHandler <|.. RouterHandler

Das Hinzufügen eines neuen Providers oder Block-Typs ist additiv — implementiere den Port, registriere den Adapter, und bestehende Aufrufstellen bleiben unverändert. Das ist es, was die Plattform austauschbar und self-hostable hält.