Für Nutzer, die Modularität v2 in Ninox 3.17 Beta in der Private Cloud testen

Hinweis: Dieser Artikel erläutert das ideale, konzeptionelle Modell der Modularität von Ninox. Es handelt sich nicht um eine Spezifikation der Modularität v2, die sich derzeit in der Beta-Phase befindet. Namen, Workflows und Verfügbarkeit können abweichen. Die neuesten Details zur Implementierung und eine Schritt-für-Schritt-Anleitung finden Sie im FAQ/Schnellstart und im Glossar.

1. Das Konzept verstehen

Modularität ist die Praxis, Software als eine Sammlung unabhängiger, interoperabler Einheiten (Module) zu erstellen. In Ninox ist ein Modul eine in sich geschlossene Datenbank, die nur ausgewählte Daten und Logik über eine bestimmte Schnittstelle gemeinsam nutzt. Da der gesamte externe Zugriff über diese Schnittstelle erfolgt, können Sie das Modul wiederverwenden, ersetzen oder aktualisieren, ohne seine interne Struktur freizugeben.

Vorteile der Modularität

• Isolation: Schemaänderungen und Fehler bleiben in dem Modul, das sie verursacht hat.
• Wiederverwendbarkeit: Ein Modul kann viele Lösungen bieten, ohne dass Logik kopiert und eingefügt werden muss.
• Aktualisierbarkeit: Sie können neue Versionen veröffentlichen, ohne Verbraucherdatenbanken zu beeinträchtigen.

2. Empfohlene Vorgehensweisen

Zunächst mag das bewusste Ausblenden von Tabellen und Feldern einschränkend wirken. Mit der Zeit sorgen minimalistische Benutzeroberflächen jedoch dafür, dass Ihre Lösung sicherer zu warten und einfacher weiterzuentwickeln ist.

Empfehlungen für eine einfachere Wartung und Entwicklung

• Lose Kopplung: Geben Sie nur das frei, was ein anderes Modul wirklich benötigt. Weniger freigegebene Felder bedeuten weniger Stellen, an denen Änderungen Auswirkungen haben.
• Aufgabentrennung: Weisen Sie jedem Modul eine einzige, klar definierte Aufgabe zu.
• Domain-Modellierung: Gestalten Sie Tabellen anhand realer Entitäten innerhalb dieser Domain.

3. Wesentliche Eigenschaften und praktische Auswirkungen

Auf einen Blick geht es bei der Modularität in Ninox um klare Verträge und kontrolliertes Teilen: Ein Modul hält seine internen Daten und Logik privat und zeigt anderen Apps nur das, was seine Schnittstelle freigibt. Dieser Ansatz bewahrt die Kapselung und ermöglicht es Teams gleichzeitig, größere Lösungen zusammenzustellen. Die Schnittstelle ist der öffentliche Vertrag – Tabellen und Felder, die Sie freigeben möchten –, sodass Verbraucherinnen nie von privaten Tabellen, Layoutfeldern oder Skripten abhängig sind.

Diese sechs wesentlichen Eigenschaften verdeutlichen, wie sich das modulare Design auf den praktischen, täglichen Gebrauch auswirkt:

• Interoperabilität basiert auf stabilen Identifikatoren. Jede freigegebene Tabelle und jedes freigegebene Feld wird in der Schnittstelle mit einer System-ID und einem öffentlichen Namen definiert. Autoreninnen behalten aus Gründen der Übersichtlichkeit ihre eigenen internen Namen bei, während Verbraucher nur den öffentlichen Namen sehen. Da der öffentliche Name einer versteckten ID zugeordnet ist, können Sie Bezeichnungen ändern, ohne Verbindungen zu unterbrechen. Die Schnittstellen-ID selbst ist der Identifikator auf API-Ebene für den Vertrag. Wenn Sie ihn ändern, wird eine neue Schnittstelle erstellt, auf die Verbraucherinnen aktualisieren müssen.
• Austauschbarkeit heißt, dass Sie Module mit minimalen Unterbrechungen austauschen können: Wenn zwei Module dieselbe Schnittstellen-ID und dieselben freigegebenen Element-IDs haben, kann ein Verbraucher zum neueren oder alternativen Anbieter wechseln, ohne bestehende Verbindungen zu unterbrechen. Genau dafür sorgt die lose Kopplung – einfachere Updates, Wiederverwendung und Austausch im Laufe der Zeit.
• Aktualisierbarkeit wird durch Versionierung und einen sicheren Upgrade-Pfad gewährleistet. Das Speichern von Änderungen an der Schnittstelle erhöht automatisch die Versionsnummer. Verbraucherinnen können mit der Arbeit an der vorherigen Version fortfahren und entscheiden, wann sie eine Verbindung zur neuesten Version herstellen möchten. Wenn eine Verknüpfung unterbrochen wird, bleiben externe Tabellen mit allen Daten in der Verbraucherdatenbank erhalten, die Synchronisierung wird jedoch unterbrochen, bis die Verbraucher die Verbindung wiederherstellen.
• Sicherheit und Zugriffskontrolle werden an der Schnittstelle erzwungen. Leserechte sind für alle freigegebenen Elemente standardmäßig aktiviert. Schreibrechte müssen den Verbrauchern hingegen explizit gewährt werden. Der Anbieter behält sich die Schreibrechte stets vor und wir empfehlen, diese nur in Ausnahmefällen zu vergeben.
• Kombinierbarkeit bedeutet, dass Sie mehrere Module zum selben Arbeitsbereich hinzufügen können – jedes in einer eigenen Datenbank mit eigener Schnittstelle – und diese mithilfe von Mustern wie Kern/Erweiterung oder gemeinsamen Referenzen überlagern können.
• Verteilung ist der Prozess des Verpackens oder Veröffentlichens eines Moduls (einschließlich seiner Schnittstelle), damit es über Arbeitsbereiche hinweg gemeinsam genutzt oder importiert werden kann.

Tipp: Wenn Sie Modularität verwenden:

• Geben Sie nur die Datenfelder frei, die Verbraucherinnen wirklich benötigen.
• Verlassen Sie sich auf öffentliche Namen und IDs, um Stabilität zu gewährleisten.
• Planen Sie Änderungen als Schnittstellenversionen.
• Bevorzugen Sie Leserechte, es sei denn, ein Workflow erfordert Schreibrechte.
• Entwerfen Sie Module so, dass sie zusammengestellt oder ersetzt werden können, ohne interne Tabellen und Skripte zu verändern.

4. Module schichten: Ein mentales Modell

Stellen Sie sich Module wie die Schichten einer Zwiebel vor. Ein Kerngeschäftsmodul (z. B. „HR“) befindet sich im Zentrum, während ergänzende Module (z. B. „Zeiterfassung“) es umgeben. Wenn „Zeiterfassung“ nur Stunden benötigt, sollten Sie es separat halten; wenn die Lohnabrechnung oder Abwesenheitsplanung tiefergehende, gemeinsam genutzte Daten erfordert, sollten Sie diese Tabellen in „HR“ belassen. Der Punkt ist, dass Daten dorthin fließen, wo sie benötigt werden – und nicht weiter.

5. Modulare vs. nicht modulare Datenbanken

Anstatt alles in einer großen App zu vereinen, zieht eine modulare Lösung klare Grenzen und verbindet diese über eine Schnittstelle.

• In einer regulären (nicht modularen) Datenbank werden Daten über Ad-hoc-Skripte und direkte Verweise ausgetauscht. Das Umbenennen eines Feldes oder einer Tabelle hat selten Auswirkungen auf andere Apps, da sich alles an einem Ort befindet. Allerdings werden dadurch verschiedene Aspekte miteinander verknüpft, was das Testen und Ersetzen erschwert.
• In einer modularen Datenbank gibt der Anbieter ausgewählte Tabellen und Felder über eine Schnittstelle frei. Die Verbraucher erhalten externe Tabellen, die diese freigegebenen Teile spiegeln und während der Verbindung synchronisiert bleiben. Da die Schnittstelle den Vertrag darstellt, können Anbieter interne Namen und Strukturen sicher ändern, während Verbraucherinnen sich auf stabile IDs und öffentliche Namen verlassen können.

6. Wie Schnittstellen Veränderungen beeinflussen – Versionierung

Schnittstellen machen Änderungen explizit. Wenn Sie anpassen, was die Schnittstelle freigibt, und dann speichern, erstellt Ninox eine neue Schnittstellenversion. Die Verbraucher arbeiten weiterhin an der vorherigen Version und können ein Upgrade durchführen, wenn sie bereit sind.

Tipp: Behandeln Sie Schnittstellenänderungen wie Produktveröffentlichungen: Kommunizieren Sie Ihre Absichten, testen Sie mit einer Verbraucherdatenbank und planen Sie die erneute Verbindung für die Verbraucherinnen.

Was zu beachten ist

• Das Ändern interner (nicht freigegebener) Felder hat keine Auswirkungen auf die Schnittstelle.
• Öffentliche Namen können verfeinert werden, ohne dass dies Auswirkungen auf die Verbraucher hat, da die IDs unverändert bleiben.
• Die Schnittstellen-ID ist Teil des Vertrags. Wenn er geändert wird, wird eine neue Schnittstelle erstellt, die von den Verbraucherinnen aktualisiert werden muss.

7. Datenaustausch und -synchronisierung – was zu erwarten ist

Wenn ein Verbraucher eine Verbindung zur Schnittstelle eines Anbieters herstellt, erstellt Ninox externe Tabellen in der Verbraucherdatenbank – eine pro freigegebener Tabelle – und füllt diese sofort mit den aktuellen Datensätzen des Anbieters.

Während die Verbindung besteht:

• Leserechte: Der Anbieter leitet Updates an die Verbraucherdatenbank weiter. Änderungen in der Verbraucherdatenbank wirken sich nicht auf den Anbieter aus.
• Schreibrechte: Updates fließen in beide Richtungen, d. h., Änderungen in der Verbraucherdatenbank werden auf den Anbieter übertragen.

Wenn die Schnittstelle entfernt oder eine Datenbank verschoben oder gelöscht wird, bleiben die ehemaligen externen Tabellen als reguläre Tabellen in der Verbraucherdatenbank erhalten. Die Synchronisierung wird beendet, aber die Daten gehen nicht verloren.

8. Benennung – IDs, interne und öffentliche Namen

Klare Namenskonventionen sind sowohl für Autoreninnen als auch für Verbraucherinnen von Vorteil.

• Interne Tabellennamen oder Feldnamen sorgen dafür, dass das Schema für Autoren lesbar bleibt, und können jederzeit geändert werden.
• Öffentliche Tabellennamen oder Tabellennamen sind das, was Verbraucher in der Benutzeroberfläche und in Formeln sehen. Sie können diese ohne Probleme ändern, da die zugrunde liegenden System-IDs unverändert bleiben.
• Schnittstellen-IDs identifizieren die Schnittstelle selbst sowohl für Autoren als auch für Verbraucherinnen. Behandeln Sie die ID wie eine versionierte API-Bezeichnung und vergeben Sie einen menschenlesbaren Namen.

9. Designrichtlinien

Gute Schnittstellen sind bewusst schlank und zielgruppengerecht gestaltet.

• Geben Sie nur das Nötigste frei. Halten Sie Abhängigkeiten gering, indem Sie nur die minimal erforderlichen Daten zwischen Modulen austauschen.
• Richten Sie Module an geschäftlichen Fähigkeiten aus. Erstellen Sie beispielsweise ein Modul „Rekrutierung” anstelle eines zu spezifischen Moduls wie „Bewerberadresse”.
• Passen Sie öffentliche Felder an die Zielgruppe an. Partner benötigen möglicherweise umfangreichere Sets, während interne Teams oft nur das benötigen, was für ihren Workflow erforderlich ist.

10. Gängige Designmuster

Verwenden Sie diese Muster, um Module einfach und dennoch effektiv zu halten:

• Kern und Erweiterung: Stellen Sie eine obligatorische Basis mit optionalen Add-ons bereit. Beispiel: „HR-Kern“ mit einem „Zeit- und Anwesenheitspaket“.
• Gemeinsame Referenz: Zentralisieren Sie Suchdaten, auf die mehrere Module zugreifen. Beispiel: Ein Ländercode-Modul, das von „Abrechnung”, „Logistik” und „CRM” verwendet wird.
• Fassade: Verbergen Sie Komplexität hinter einer schlanken, schreibgeschützten Tabelle, die wichtige Kennzahlen aus mehreren Tabellen aggregiert. Beispiel: Ein Projekt-Dashboard, das KPIs zurückgibt.

11. Wohin als nächstes

• Schritt-für-Schritt-Anleitungen für Modulautoren und -verbraucher finden Sie unter FAQ und Schnellstart.
• Genaue Definitionen von Rollen, Feldern, Namen und Berechtigungen finden Sie im Glossar.