Die CodamAI-Module

Worum es geht

CodamAI ist die Software-Factory der Codamic AG. Damit baut man Geschäftsanwendungen, ohne jedes Mal bei null anzufangen. CodamAI besteht aus mehreren Modulen. Jedes Modul übernimmt eine klar abgegrenzte Aufgabe:

• CDMS (CodamAI Data Management System) verwaltet die Daten: Modelle, REST-API, Datenbank, Dateien, Historie.
• CIAS (CodamAI Identity & Access System) regelt Identität und Zugang: Benutzer, Mandanten, Rollen, Registrierung.
• CRMS (CodamAI Reporting Management System) erzeugt Berichte aus Vorlagen.
• Der Hub ist die zentrale Oberfläche mit seinem Backend. Dort legst du Projekte an, modellierst deine Daten und verwaltest den Zugang.

Darunter liegen gemeinsame Bausteine, die alle Java-Module teilen. Neben allem steht Keycloak, der Identity Provider. Dort melden sich die Menschen an.

Die Modulkarte

Jedes Modul hat eine feste Farbe. Dieselben Farben siehst du auf allen Seiten dieser Doku.

flowchart TB
    subgraph HUBG["Hub"]
        direction LR
        HF["Hub-Oberfläche<br/>hub-frontend"]
        HB["Hub-Backend<br/>hub-backend<br/>+ MCP-Server"]
    end
    CP["CDMS-Portal<br/>Modellieren"]
    CIP["CIAS-Portal"]
    CDMS["CDMS<br/>Datenschicht, Generator,<br/>Projektrahmen"]
    CIAS["CIAS<br/>Identität und Zugang"]
    CRMS["CRMS<br/>Berichte aus Vorlagen"]
    KC["Keycloak<br/>Identity Provider"]
    G["Gemeinsame Bausteine<br/>global-parent, commons,<br/>commons-persistence"]

    HF --> HB
    CP --> HB
    CIP --> HB
    HB -- "ist gebaut mit" --> CDMS
    HB -- "bettet ein" --> CIAS
    CRMS -- "ist gebaut mit" --> CDMS
    CRMS -- "nutzt" --> CIAS
    CIAS -- "Adapter" --> KC
    CDMS --> G
    CIAS --> G

    classDef hub fill:#4f46e5,stroke:#4f46e5,color:#fff
    classDef cdms fill:#1976d2,stroke:#1976d2,color:#fff
    classDef cias fill:#8e24aa,stroke:#8e24aa,color:#fff
    classDef crms fill:#ffc107,stroke:#b38600,color:#1f1a00
    classDef idp fill:#c2410c,stroke:#c2410c,color:#fff
    classDef shared fill:#64748b,stroke:#64748b,color:#fff
    class HF,HB hub
    class CDMS,CP cdms
    class CIAS,CIP cias
    class CRMS crms
    class KC idp
    class G shared

Die Pfeile lesen sich so: „Das Hub-Backend ist mit CDMS gebaut und bettet CIAS ein.“ Einbetten heißt: CIAS läuft als Baustein im selben Programm mit, nicht als eigener Dienst. Was das bedeutet, erklärt Eingebettet und getrennt im Vergleich.

Die Module einzeln

Ein paar Wörter aus der Tabelle:

• Ein Modell beschreibt eine Art von Ding, das deine Anwendung kennt, etwa „Kunde“ mit seinen Feldern. Mehr dazu unter Modellieren im Hub.
• Ein Mandant ist ein Kunde deiner Anwendung, dessen Daten von allen anderen getrennt sind.
• Ein Hook ist eigener Code, der sich in einen Ablauf von CDMS einhängt.
• MCP (Model Context Protocol) ist ein Protokoll, über das KI-Clients Werkzeuge aufrufen. Der MCP-Server des Hubs lässt sie Modelle lesen und kontrolliert ändern, siehe Schemaänderung über den MCP-Server.

Die Landkarte der Repositories

Jedes Modul besteht aus mehreren Repositories, also eigenen Git-Projekten. Es gibt vier Arten:

• Bibliothek: ein Java-Baustein (JAR), den andere Projekte einbinden. Er läuft nie allein.
• Dienst: ein Programm, das allein startet und Anfragen beantwortet.
• Oberfläche: eine Web-Anwendung (Nuxt) mit eigenem Server, dem BFF. Was ein BFF ist, steht unter Die Beteiligten einer Anfrage.
• Werkzeug: etwas, das beim Bauen, Testen oder in Keycloak läuft.

flowchart LR
    subgraph GEM["Gemeinsam"]
        direction TB
        gp["global-parent"]
        co["commons"]
        cpe["commons-persistence"]
    end
    subgraph CD["CDMS"]
        direction TB
        cdl["cdms-commons · cdms-rest-api<br/>cdms-system-layer · cdms-authorization<br/>cdms-persistence-database<br/>cdms-localfs-storage"]
        cdw["cdms-generator · cdms-scaffold<br/>cdms-parent · cdms-integrationtest"]
        cdf["CDMS/frontend<br/>(CDMS-Portal)"]
    end
    subgraph CI["CIAS"]
        direction TB
        cil["cias-kernel · cias-authentication<br/>cias-tenancy · cias-user<br/>cias-authorization · cias-registration<br/>cias-notification · cias-audit<br/>cias-iam-api · cias-iam-keycloak<br/>cias-iam-memory · cias-tenancy-client<br/>cias-spring-boot-starter"]
        cir["cias-runtime"]
        ciw["cias-parent · cias-test-support<br/>cias-integrationtest<br/>cias-iam-keycloak-provider"]
        cif["cias-frontend<br/>(CIAS-Portal)"]
    end
    subgraph HU["Hub"]
        direction TB
        hb["hub-backend"]
        hf["hub-frontend"]
        hl["hub-login"]
    end
    subgraph CR["CRMS"]
        direction TB
        crb["crms-backend-mvp"]
        crf["crms-frontend-mvp"]
    end

    classDef hub fill:#4f46e5,stroke:#4f46e5,color:#fff
    classDef cdms fill:#1976d2,stroke:#1976d2,color:#fff
    classDef cias fill:#8e24aa,stroke:#8e24aa,color:#fff
    classDef crms fill:#ffc107,stroke:#b38600,color:#1f1a00
    classDef shared fill:#64748b,stroke:#64748b,color:#fff
    class gp,co,cpe shared
    class cdl,cdw,cdf cdms
    class cil,cir,ciw,cif cias
    class hb,hf,hl hub
    class crb,crf crms

Gemeinsame Bausteine

CDMS

CIAS

Hub

CRMS

Dokumentation

Wie die Module zusammenhängen

Abhängigkeiten zeigen immer nach unten: Eine Anwendung bindet Bibliotheken ein, Bibliotheken binden die gemeinsamen Bausteine ein. Nie umgekehrt.

flowchart BT
    GP["global-parent"]
    CO["commons"]
    CPE["commons-persistence"]
    CDL["CDMS-Bibliotheken"]
    CIL["CIAS-Bibliotheken"]
    GEN["cdms-generator<br/>(beim Build)"]
    HB["hub-backend"]
    CRB["crms-backend-mvp"]
    APP["deine CDMS-Anwendung"]
    CIR["cias-runtime"]

    CO --> GP
    CPE --> CO
    CDL --> CO
    CDL --> CPE
    CIL --> CO
    CIL --> CPE
    HB --> CDL
    HB --> CIL
    CRB --> CDL
    CRB --> CIL
    APP --> CDL
    APP --> CIL
    CIR --> CIL
    GEN -. "erzeugt Code für" .-> HB
    GEN -. "erzeugt Code für" .-> CRB
    GEN -. "erzeugt Code für" .-> APP

    classDef hub fill:#4f46e5,stroke:#4f46e5,color:#fff
    classDef cdms fill:#1976d2,stroke:#1976d2,color:#fff
    classDef cias fill:#8e24aa,stroke:#8e24aa,color:#fff
    classDef crms fill:#ffc107,stroke:#b38600,color:#1f1a00
    classDef shared fill:#64748b,stroke:#64748b,color:#fff
    classDef build fill:#57534e,stroke:#57534e,color:#fff
    class GP,CO,CPE shared
    class CDL,APP cdms
    class CIL,CIR cias
    class HB hub
    class CRB crms
    class GEN build

Drei Dinge fallen auf:

1. Jede CDMS-Anwendung ist gleich gebaut. Das Hub-Backend, das CRMS-Backend und deine eigene Anwendung binden dieselben CDMS-Bibliotheken ein. Der Generator erzeugt für alle drei den Code aus ihrem Modell. Die Modelle deiner Anwendung holt er aus dem Hub, siehe Codegenerierung im Build.
2. CIAS kommt als Bibliotheken. Eine Anwendung mit Anmeldung bindet cias-authentication ein, damit jede Anfrage durch die Filterkette läuft. Ob die übrigen CIAS-Module mit im selben Prozess laufen oder in cias-runtime, ist die Betriebsart, siehe Eingebettet und getrennt im Vergleich.
3. Keycloak kennt nur ein Modul. Einzig der Adapter cias-iam-keycloak spricht mit der Verwaltungs-API von Keycloak. Warum, steht unter CIAS als Brücke zum Identity Provider.

Welche Art von Repository ist das?

Fallen

Weiter

• Die Beteiligten einer Anfrage: wer bei einer Anfrage mit wem spricht
• Die wichtigsten Begriffe in Bildern
• Wer entscheidet was?
• Eingebettet und getrennt im Vergleich