Kernkonzepte

Die Kernidee

dForge verwandelt Geschäftsdefinitionen in laufende Anwendungen. Sie beschreiben, was Ihr Geschäft braucht — Entitäten, Felder, Ansichten, Sicherheitsregeln — und die Plattform regelt, wie es gebaut, ausgerollt und abgesichert wird.

Das ist der metadatengesteuerte Ansatz. Es gibt keinen Codegenerierungs-Schritt, der Dateien produziert, die Sie pflegen müssen. Die Plattform liest Metadaten zur Laufzeit und verhält sich entsprechend.

Mandanten

Ein Mandant ist ein isolierter Workspace mit eigener Datenbank. Jede Organisation, die dForge nutzt, ist ein Mandant.

• Eine PostgreSQL-Datenbank pro Mandant
• Ein Datenbank-Benutzer pro Mandant
• Module pro Mandant installiert — verschiedene Organisationen können verschiedene Kombinationen nutzen
• Keine geteilten Tabellen, keine geteilten Metadaten, kein Risiko von mandantenübergreifenden Datenlecks

Eine separate Auth-Datenbank speichert Benutzerkonten und verfolgt, auf welche Mandanten jeder Benutzer Zugriff hat.

Module

Ein Modul ist ein in sich abgeschlossenes Paket aus Geschäftsfunktionalität:

• Entitäten (Datenbanktabellen)
• Ansichten (wie Daten dargestellt werden)
• Menüs (Navigationsstruktur)
• Rollen (Sicherheitsdefinitionen)
• Aktionen (eigene Geschäftsoperationen)
• Einstellungen (konfigurierbare Werte)
• Initialdaten (Ausgangsdatensätze)

Module werden pro Mandant installiert. Die Installation eines Moduls legt seine Datenbanktabellen an, registriert seine Metadaten und fügt seine Menüs zur Benutzeroberfläche hinzu.

Module können von anderen Modulen abhängen und einander über Brücken-Module erweitern. Eine crm-finance-Brücke fügt Angebot-zu-Rechnung-Konvertierung hinzu, ohne CRM oder Finanzen zu verändern.

Für eine tiefere Einführung in das Modulkonzept — Anatomie, Komposition, Ökosystem-Stufen und Vergleich mit Alternativen — siehe Was ist ein dForge-Modul?.

Entitäten

Eine Entität ist ein Geschäftsobjekt — eine Tabelle in der Datenbank. Beispiele: Konto, Kontakt, Rechnung, Mitarbeiter, Bestandsbewegung.

Jede Entität hat:

• Code — den Tabellennamen (z. B. account)
• Felder — die Spalten
• Constraints — Prüfregeln und eindeutige Indizes
• Ansichten — Wege, die Daten der Entität darzustellen
• Aktionen — eigene Operationen, die für Datensätze verfügbar sind

Siehe die Felder-Referenz für die vollständige Liste der Feldtypen.

Ansichten

Eine Ansicht definiert, wie Anwender Entitätsdaten sehen und mit ihnen interagieren. Jeder Menüpunkt verlinkt auf eine Ansicht. Ansichten kombinieren eine Datenquelle (welche Datensätze gezeigt werden) mit einem Layout (wie sie dargestellt werden).

Ansichtstypen: Grid, Karte, Kanban, Kalender, Liste, Galerie.

Siehe den Ansichten-Leitfaden für Details.

Ordner

Ein Ordner ist eine dynamische gefilterte Ansicht, kein physischer Container. Datensätze „gehören“ keinem Ordner — sie erscheinen in ihm, wenn sie zum Filter des Ordners passen, und derselbe Datensatz kann in vielen Ordnern gleichzeitig auftauchen.

Ordner sind das einheitliche Navigationskonzept in dForge. Top-Level-Ordner entsprechen den installierten Modulen, aber alles darunter — Abteilungen, Regionen, Status, eigene Abfragen — ist ebenfalls ein Ordner. Der Begriff „Modul“ ist intern; Anwender sehen Ordner durch und durch.

Jeder Ordner definiert:

• Filterkriterien — welche Datensätze erscheinen (z. B. status = 'draft')
• Rollenzuweisungen — wer welche Berechtigungen innerhalb dieses Ordners hat
• Feld-Overrides — ein Feld kann in einem Ordner editierbar und in einem anderen schreibgeschützt sein
• Einstellungs-Overrides — Modul-Einstellungen können pro Ordner unterschiedlich sein

Ordner sind hierarchisch. Unterordner erben Sicherheit und Einstellungen von ihrem übergeordneten Ordner, sofern sie nicht explizit isoliert sind.

Sicherheitsmodell

dForge verwendet ein geschichtetes Sicherheitsmodell:

• Rollen definieren, auf welche Entitäten, Aktionen, Berichte und Ordner ein Anwender Zugriff hat. Entitätsrechte verwenden Buchstabencodes: S (Select), I (Insert), U (Update), D (Delete), C (Clone). Aktionen, Berichte und Ordner verwenden E (Execute/Access).
• Ordner definieren, welche Datensätze ein Anwender sehen kann (Sicherheit auf Zeilenebene per Filter)
• Ansichten definieren, welche Felder sie sehen können (Sicherheit auf Spaltenebene)
• Aktionen können ihre eigenen Berechtigungsregeln haben (canExecute-Formeln)

Rollen sind additiv — mehrere Rollen vereinen ihre Berechtigungen, widerrufen sie aber niemals. Ein Anwender mit Rollen, die SU und SIC gewähren, hat am Ende SIUC.

Rollen können ordnergebunden sein — ein Anwender kann global hr.manager sein, aber innerhalb des Ordners „Geschäftsleitung“ nur hr.viewer.

Siehe den Administrations-Leitfaden für das vollständige Sicherheitsmodell.

Formeln

Formeln sind Ausdrücke, die in der gesamten Plattform verwendet werden:

• Berechnete Spalten — Werte aus anderen Feldern berechnen
• Validierungsregeln — Geschäftslogik durchsetzen
• Aktions-Bedingungen — steuern, wann Aktionen verfügbar sind
• Sicherheit auf Zeilenebene — einschränken, welche Datensätze sichtbar sind
• Standardwerte — Anfangswerte für neue Datensätze setzen

Formeln können andere Felder mit [field_name] referenzieren, über Referenzen mit [field].[other_field] navigieren und eingebaute Funktionen wie IF, TODAY, NOW verwenden.

Siehe die Formel-Referenz für die vollständige Syntax.

Aktionen

Aktionen sind eigene serverseitige Operationen jenseits des grundlegenden CRUD. Beispiele:

• Einen Lead in ein Konto, einen Kontakt und eine Verkaufschance konvertieren
• Eine Rechnung aus einem Angebot generieren
• Bestand zwischen Lagern transferieren

Aktionen werden in einer einfachen DSL mit drei Blöcken definiert: params: (was der Anwender bereitstellt), canExecute: (wann die Aktion verfügbar ist) und execute: (was passiert). Die DSL hat Zugriff auf die Felder des aktuellen Datensatzes, Parameter und eingebaute Funktionen für Abfragen, Inserts und Benachrichtigungen.

Siehe den Aktionen-Leitfaden für Details.

Lokalisierung

dForge ist von Grund auf für mehrsprachige Abläufe gebaut.

Übersetzbare Metadaten

Jede Metadaten-Definition unterstützt Übersetzungen:

• Entitätsnamen und -beschreibungen
• Feldbezeichnungen und Tooltips
• Menüpunkte und Sektionsnamen
• Aktionsnamen und Parameter-Labels
• Modulnamen und Einstellungen

Übersetzungen werden getrennt von den strukturellen Metadaten gespeichert, damit Sie neue Sprachen hinzufügen können, ohne Entitätsdefinitionen anzufassen.

Mandantenspezifische Übersetzungs-Overrides

Mandanten können Standardübersetzungen überschreiben. Ein branchenspezifisches Deployment kann „Konto“ in „Patient“ oder „Kunde“ umbenennen, ohne das Modul zu forken.

Lokalisierte Darstellung

Die Benutzeroberfläche respektiert das Locale des Anwenders für:

• Datums- und Zeitformatierung
• Zahlen- und Währungsformatierung
• Übersetzte Labels und Meldungen

Module liefern Standardübersetzungen mit und können locale-spezifische Initialdaten enthalten.

API

dForge stellt RPC-artige Endpunkte für alle Operationen bereit:

POST /api/exec      # authentifizierte Aufrufe
POST /api/invoke    # Aufrufe ohne Session (Login, Passwort-Reset)

/api/exec nimmt einen Methodennamen, Parameter und einen Ordner-Kontext entgegen (Sicherheit ist ordnergebunden, nicht global). Das Methodenregister umfasst:

• data.get — Datensätze abfragen
• data.set — Datensätze einfügen, aktualisieren oder löschen
• action.execute — eine Aktion ausführen
• action.getEntityActions — verfügbare Aktionen für eine Entität auflisten
• report.run — einen Bericht ausführen
• settings.list, settings.set — Modul-Einstellungen verwalten

Mehrere Methodenaufrufe können in einer einzigen Anfrage gebündelt werden, mit hierarchischen Unter-Anfragen und positionsbasierten Antworten. Das Frontend-SDK bündelt Aufrufe automatisch, die im selben Microtask gemacht werden. Dateien werden über GET /api/file/{folder}/{entity}/{field}/{key} ausgeliefert.

Hinweis: Eine klassische REST-API ist für externe Integrationen auf der Roadmap. Aktuell sind der RPC-Endpunkt und das Frontend-SDK die unterstützten Integrationspunkte.

Audit & Historie

Jede Datenänderung kann verfolgt werden:

• Wer die Änderung gemacht hat
• Was sich geändert hat (alter Wert, neuer Wert)
• Wann es passiert ist
• Welche Aktion oder welcher API-Aufruf es ausgelöst hat

Module können vollständige Audit-Historie für sensible Entitäten aktivieren (z. B. aktiviert das Finanzmodul es für alle Finanztransaktionen).

Nächste Schritte

• Anwenderleitfaden — als Endanwender mit Daten arbeiten
• Administration — Anwender, Rollen und Ordner verwalten
• Studio-Leitfaden — Module visuell bauen
• Felder-Referenz — alle Feldtypen und ihre Optionen
• Ansichten-Leitfaden — Grid-, Karten-, Kanban-, Kalender-, Listen-Layouts
• Formel-Referenz — Ausdrucks-Syntax und Funktionen
• Aktionen-Leitfaden — eigene DSL-Operationen