Modellierung im CDMS-Hub
Kurzantwort: Der CDMS-Hub ist die zentrale Stelle, an der Datenmodelle entstehen: Projekte, Module, Ordner, Modelle, Felder, Beziehungen, Enumerationen, Endpunkte, Rollen und Hooks. Aus diesen Angaben entsteht die Modellbeschreibung, aus der der Generator beim Build Ihren Anwendungscode erzeugt. Bedienen lässt sich der Hub über seine Oberfläche oder über den MCP-Server.
Die Rolle des Hubs
Abschnitt betitelt „Die Rolle des Hubs“flowchart LR
UI["Modellierungs-<br/>oberfläche"] --> HB["CDMS-Hub"]
MCP["KI-Client über MCP"] --> HB
HB --> DD[("Design-Daten:<br/>Projekte · Module · Modelle · Felder")]
HB -->|Export| Y["Modellbeschreibung<br/>system · folders · models · enumerations"]
Y --> GEN[CDMS-Generator]
GEN --> APP["Ihre Anwendung<br/>generierter Spring-Boot-Code"]
Ein CDMS-System (in der Oberfläche: Modul) gehört zu einem Projekt; maßgeblich ist seine UUID. Diese UUID gibt Ihr Build dem Generator mit, damit er die richtigen Modelle lädt – siehe Generierung.
Das Meta-Modell
Abschnitt betitelt „Das Meta-Modell“Was Sie im Hub anlegen können und welche Angaben dazugehören:
| Ressource | Wesentliche Angaben |
|---|---|
| Projekt | gruppiert Module, Status |
| Modul / System | api, storage, authentication, database, monitoring, version, coreVersion, enthaltene Items |
| Item | name, description, Modul, Ordner – Oberbegriff für Ordner, Modelle und Enumerationen |
| Ordner | path, enthaltene Items; Hierarchie über die Ordner-Referenz |
| Modell | modelType, singleton, auditing, extendsModel, Felder, Endpunkte, Rollen, Hooks |
| Datenmodell | konkret instanziierbar (@type=datamodel) |
| Abstraktes Modell | Basis für Untertypen (@type=abstractmodel) |
| Datei-Modell | Modell mit Upload und Download |
| Feld | name (Muster [A-Za-z0-9_]{1,50}), Regeln, Rollen |
| Primitivfeld | type, length, defaultValue |
| Enum-Feld | Referenz auf eine Enumeration, Vorgabewert |
| Beziehungsfeld | relationship, Spiegelfeld auf der Gegenseite, recursive |
| Regel | Regeltyp und Vergleichswert |
| Rolle | type, auf Modell- und auf Feldebene |
| Endpunkt | type |
| Hook | type |
| Enumeration und Enum-Wert | Werte und die Felder, die darauf verweisen |
| Zugriffsfilter | Profilattribut, gefiltertes Feld, Modell |
Die Auswahllisten
Abschnitt betitelt „Die Auswahllisten“| Liste | Werte |
|---|---|
| Feldtyp | STRING, INTEGER, FLOAT, DOUBLE, BOOLEAN, DATE, TIME, DATE_TIME |
| Beziehung | ONE_TO_ONE, ONE_TO_MANY, MANY_TO_ONE, MANY_TO_MANY |
| Rollenart | CREATE, READ, UPDATE, DELETE |
| Endpunktart | CREATE, READ, UPDATE, DELETE, LIST, UPLOAD, DOWNLOAD, HISTORY_READ, HISTORY_QUERY, HISTORY_ROLLBACK |
| Modell-Scope | TENANT, SYSTEM, USER |
| Rekursion | CREATE, UPDATE, DELETE |
| Hook-Art | CUSTOM |
Welche Werte Ihr Hub tatsächlich unterstützt, liefert über MCP
cdms_get_capabilities – das ist die verlässlichere Quelle als eine Tabelle in
einer Dokumentation.
Regeln am Feld
Abschnitt betitelt „Regeln am Feld“Verstanden werden (mit oder ohne führendes @):
@nullable, @notnull, @notnulloncreate, @notnullonupdate, @pattern,
@size, @min, @max, @unique
Was sie zur Laufzeit bewirken, steht unter Validierung.
Modellierungsregeln
Abschnitt betitelt „Modellierungsregeln“Diese Regeln setzt der Hub durch – gut zu wissen, bevor Sie modellieren:
- Item-Namen sind pro Ordner eindeutig.
- Vererbungsziel ist immer ein abstraktes Modell.
- Der Modell-Scope ist Pflicht, Standard ist
TENANT. - Ordnerpfade verwaltet der Hub selbst – sie ergeben sich aus der Hierarchie, nicht aus einer Eingabe.
- Enum-Werte haben keine feste Ordnung; angezeigt wird alphabetisch.
- Umbenennen ist erlaubt, warnt aber: Bestehende Daten und generierter Code hängen an den Namen.
- Zyklen beim Verschieben von Ordnern werden serverseitig abgelehnt.
Sicherheit
Abschnitt betitelt „Sicherheit“Alle Zugriffe – auch die des MCP-Servers – laufen über die zugriffsgeprüften Schichten des Hubs, nie direkt auf die Datenbank. Mandanten-, Owner- und Rechteprüfung greifen deshalb unverändert: Sie sehen und ändern genau die Systeme, für die Ihr Zugang berechtigt ist.