CodamAI – Plattformüberblick

Kurzantwort: CodamAI ist eine Software-Factory für individuelle Unternehmenssoftware. Ihr Kern ist CDMS, eine modellgetriebene Spring-Boot-Basis, die aus einem Datenmodell Entities, DTOs, Payloads, Mapper, REST-APIs, Service- und Persistenzschichten erzeugt. Um CDMS herum liegen weitere Module für Identität, Frontend, Prozesse und Reporting sowie der Hub, in dem die Datenmodelle gepflegt werden.

---

Die Module

Modul	Name	Zweck
CDMS	CodamAI Data Management System	Datenmodellierung, Persistenz, APIs, CRUD, Mandantenfähigkeit, Auditing, Dateien
CIAS	CodamAI Identity & Access System	Authentifizierung, Token, Rollen, Mandanten-Kontext
CADS	CodamAI App Development System	App-/Mobile-Entwicklung
CFDS	CodamAI Frontend Development System	Frontend-Komponenten und Generatoren
CPMS	CodamAI Process Management System	Prozesse, Workflows, Aufgaben, Zustände
CRMS	CodamAI Reporting Management System	Reports, HTML/PDF/XML-Export, Vorlagen

Diese Dokumentation beschreibt CDMS und die für die Anbindung nötigen Teile von CIAS. Die übrigen Module sind hier nur der Vollständigkeit halber genannt.

Wie die Teile zusammenspielen

flowchart TB
    subgraph Entwurf
        HUB["CDMS-Hub<br/>Datenmodelle, Felder, Beziehungen,<br/>Endpunkte, Rechte"]
    end

    subgraph Build
        GEN["CDMS-Generator<br/>Annotation-Processor"]
    end

    subgraph "Ihre Anwendung"
        API[REST-API]
        SYS[System-Layer]
        HOOK["Hooks<br/>eigene Businesslogik"]
        PERS[Persistenz]
        FILES[Dateiablage]
    end

    subgraph Laufzeit
        KEY[(Keycloak / CIAS)]
        SDB[(System-Datenbank)]
        TDB[(Mandanten-Datenbanken)]
        VOL[(Dateispeicher)]
    end

    HUB -->|Modell als YAML| GEN
    GEN -->|generierter Code| API
    API --> SYS
    SYS --> HOOK
    SYS --> PERS
    SYS --> FILES
    API -.Token prüfen.-> KEY
    PERS --> SDB
    PERS --> TDB
    FILES --> VOL

Der Ablauf in einem Satz: Sie modellieren im Hub, der Generator erzeugt daraus beim Build eine vollständige Spring-Boot-Anwendung, und Ihre Fachlogik kommt über Hooks dazu.

Was CDMS ausmacht

1. Model First – das Datenmodell ist die Quelle. Aus ihm werden pro Modell rund 20 Klassen erzeugt (siehe Generierung).
2. Generated but Extendable – der generierte Code wird nicht von Hand geändert. Fachlogik kommt über Hooks.
3. API First – jedes Modell bekommt einen festen Satz REST-Endpunkte (siehe Endpunkte).
4. Response Requests – der Client bestimmt im Payload, welche Felder und Beziehungen zurückkommen (siehe Response Requests).
5. Tenant Awareness – Systemdaten, Mandantendaten und Benutzerdaten sind technisch getrennt (siehe Mandantentrennung).
6. Auditability – Änderungen sind über Hibernate Envers nachvollziehbar und rollbackfähig (siehe Auditing).

Technologiestand

Das ist der Stack, den Sie in einer generierten Anwendung vorfinden:

Bereich	Technologie
Sprache	Java 24
Framework	Spring Boot (Web/REST, Validation, Mail), kein Spring Data JPA für die CDMS-Kernpfade
ORM	Hibernate + Hibernate Envers, Criteria API
Mapping	MapStruct, generierte Mapper
Boilerplate	Lombok
Datenbank	MySQL 8 (produktiv), H2 (Test)
Dateien	lokales Dateisystem, S3 und Azure Blob als austauschbare Backends
Auth	Keycloak (OIDC/JWT) über die CIAS-Bibliothek
Build	Maven, optional GraalVM Native Image
Betrieb	Docker, Kubernetes

Das Frontend ist nicht vorgegeben: CDMS liefert eine REST-API, die sich mit jedem Stack ansprechen lässt. Wie eine Anbindung aussieht, zeigt API-Nutzung im Frontend.

Positionierung

CDMS ist kein Low-Code-Baukasten. Es erzeugt echte, erweiterbare Spring-Boot-Anwendungen mit klaren APIs, mandantenfähiger Datenhaltung, Rechteprüfung, Auditierung und Erweiterungspunkten für projektspezifische Businesslogik. Der erzeugte Code gehört dem Projekt und ist auch ohne die Factory weiter betreibbar.