Zum Hauptinhalt springen

Konzept & Architektur

Der Information Toolbench modelliert Metadaten und liefert sie aus. Das sind nicht zwei Funktionen, sondern ein Gedanke — und aus ihm folgt die Bauform des Produkts. Diese Seite erklärt, wie Client, API und Template Engine zusammenhängen, und warum jeder Teil sich weigert zu wissen, was die anderen erledigen.

Keine Metadaten ohne Auslieferung​

Ein Modell, das nichts hervorbringt, ist die Dokumentation einer Absicht. Jemand schreibt es, alle nicken es ab, und die Plattform, die es beschreibt, wird trotzdem von Hand gebaut — danach laufen beide auseinander, und nur eines davon ist echt.

ITB ist so gebaut, dass das Modell das ist, was läuft. Was Sie zeichnen, wird zu Artefakten, und diese Artefakte führt Ihre Plattform aus.

Vom Modell zur laufenden PlattformDas Modell speist einen generischen Generator. Ein Pack liefert die Regeln. Der Generator schreibt Artefakte — SQL, dbt-Modelle, Dokumentation — und die laufen auf der Zielplattform. Ein anderes Pack ändert das Ergebnis, ohne die Anwendung zu ändern.Ihr ModellEntitäten, Beziehungen,Attribute, TypenGeneratoreine generische Maschinefür jedes ErgebnisArtefakteSQL, dbt-Modelle,DokumentationIhrePlattformDAS PACKVorlagen und Regeln

Die Maschine in der Mitte weiß nichts über Data Vault, über dbt oder über irgendein anderes Ziel. Das alles steckt in einem Pack. Ein anderes Pack ändert, was hinten herauskommt, ohne dass jemand die Anwendung ändert — und genau deshalb ist ein zweiter Anwendungsfall eine Frage der Konfiguration und nicht eines Releases.

Ein Produkt, drei Zuständigkeiten​

Client, API und Template EngineDer Client zeichnet und bearbeitet und fragt die API, was er anbieten darf. Die API ist der führende Bestand und entscheidet über den Capability-Satz. Die Template Engine läuft in der API und macht aus dem Modell Dateien. Packs ergänzen Capabilities und Vorlagen zur Laufzeit.Clientzeichnet und bearbeitet das ModellMenüs, Assistenten, Zeichenflächekennt kein Data Vault,kein dbt, keine FachlichkeitAPIder führende Bestandliefert den Capability-Satzentscheidet, was dieseInstallation darfTemplate Enginemacht aus dem Modell Dateienläuft in der APIdie Regeln stehen im Pack,nicht in der Maschinedas ModellCapabilitiesPACKS — IM BETRIEB INSTALLIERTCapability-Packs ergänzen Menüs und Assistenten · Template-Packs ergänzen Generatorender Schlüssel in Ihrer Lizenz entscheidet, welche sich öffnenModellablage & GitVersionen, Verlauf, Wiederherstellung

Der Client ist mit Absicht uninteressiert. Er stellt dar, was man ihm gibt: jeder Menüeintrag, jeder Assistent und jeder Schreibvorgang ist ein JSON-Deskriptor, den die API ihm zur Laufzeit liefert. Einen Assistenten hinzuzufügen heißt, einen Deskriptor hinzuzufügen, keine Komponente — und es kann kein Menü erscheinen, das der Server nicht angeboten hat.

Die API ist der führende Bestand und der Ort, an dem die Frage „was darf diese Installation?" beantwortet wird. Ihr Modell liegt dort; der Browser hält eine Arbeitskopie, damit das Bearbeiten unmittelbar bleibt — wie beide in Takt bleiben, steht unter Modell-Persistenz. Auch welche Funktionen es gibt, wird hier entschieden; deshalb ist die Feature Matrix eine Eigenschaft Ihrer Installation und nicht Ihres Downloads.

Die Template Engine ist die Auslieferungshälfte, und sie sitzt in der API, weil die Generierung das Modell braucht und nicht den Bildschirm. Wie ein Pack sie steuert, steht unter Wie die Generierung funktioniert.

Das Metamodell ist das, was Sie anpassen​

Die meisten Werkzeuge lassen Sie eine feste Struktur ausfüllen. ITB lässt Sie die Struktur selbst formen: welche Arten von Objekten es gibt, wie sie zueinander stehen dürfen, was über sie festgehalten werden muss. Diese Schicht ist das Metamodell, und sie ist die einzige, die Sie anfassen müssen, damit ITB Ihre Welt beschreibt.

Metamodell, Modell und SichtDrei Schichten. Das Metamodell sagt, was es geben darf, und dort findet die Anpassung statt. Das Modell ist das, was es gibt. Ansichten und Zeichenfläche sind Fenster auf genau dieses Modell, nie eine zweite Kopie davon.Metamodellwas es geben darf — die Schicht, die Sie formenkein Fork, kein Release: das ist KonfigurationModellwas es gibt — Ihre Entitäten, ihre Attribute, ihre BeziehungenSichtAnsichten und Zeichenfläche — Fenster auf das Modell, nie eine zweite KopieEntitätstypenBeziehungstypenAnsichtenEigene MerkmaleCapability-Deskriptorenschränkt einwird dargestellt als

Die visuelle Darstellung ist eine Sicht, kein zweites Modell. Eine Ansicht entscheidet, welchen Teil des Modells Sie sehen und wo die Kästen liegen; eigene Objekte hält sie nie. Entfernen Sie eine Entität aus einer Ansicht, steht sie weiterhin im Modell — deshalb können zwei Personen dasselbe Modell durch völlig verschiedene Fenster betrachten, ohne dass eine von ihnen eine private Fassung der Wahrheit besitzt.

Dieselbe Schicht trägt die Capability-Deskriptoren: JSON, das einen Menüeintrag erklärt, den Assistenten dahinter und die Transaktion, die er schreibt. Deshalb ist eine neue Modellierungsaktion etwas, das man erklärt, statt etwas, das jemand baut — siehe Deskriptoren und Primitive.

Was daraus folgt​

  • Ein anderes Ergebnis ist ein anderes Pack, kein anderes Produkt. Die Maschine ändert sich nicht, wenn das Ziel sich ändert.
  • Eine andere Fachlichkeit ist ein anderes Metamodell. Typen und eigene Merkmale sind Daten, also ist eine neue Welt zu beschreiben Konfiguration und keine Entwicklung.
  • Die Edition entscheidet sich im Betrieb. Ein Client-Bau, ein Image je Edition, und die API liefert den Capability-Satz, den Ihre Lizenz erlaubt — siehe Feature Matrix.
  • Was Sie zeichnen, wird ausgeliefert. Es gibt keine zweite, von Hand gepflegte Wahrheit weiter unten, weil die Artefakte aus genau dem Modell entstehen, das Sie vor sich haben.