Tutorial: Domain Pack veroeffentlichen

In diesem Tutorial nimmst du ein funktionierendes Tenant-AFS, extrahierst es in ein wiederverwendbares Domain Pack und verwendest es um einen zweiten Tenant zu erstellen. So skalieren Beratungsfirmen ihre Expertise — einmal bauen, vielfach einsetzen.

Zeit: 20 Minuten Voraussetzungen: Ein funktionierender Tenant mit Signals, Theses und mindestens einem erfolgreichen Build

1. Wann ein Pack erstellen

Du hast mit einem Kunden gearbeitet. Dein AFS hat:

• Entity-Definitionen und Contracts
• Source-System-Dispatch-Macros
• 10+ Signals, Theses, Verdicts
• SMEbits aus Experteninterviews
• Reports

Jetzt fragt ein zweiter Kunde derselben Branche nach derselben Analyse. Statt Dateien manuell zu kopieren, paketierst du dein Framework als Domain Pack.

2. Die Struktur

Ein Domain Pack ist einfach ein Git-Repository mit der richtigen Struktur:

jinflow-pack-mypack/
  jinflow.yml              ← Pack-Manifest
  entities/                ← Entity-Definitionen
  contracts/               ← gold, silver, findings, diagnosis, smebit, bitbundle
  probes/                  ← Signal-Definitionen
  hypotheses/              ← Thesis-Definitionen
  diagnoses/               ← Verdict-Definitionen
  smebits/                 ← Expertenwissen (Pack-Level, nicht Tenant-spezifisch)
  bitbundles/              ← kuratierte Narrative
  reports/                 ← Report-Deklarationen
  lineage/                 ← Lineage-Definitionen
  dbt/{pack}/              ← dbt-Projekt (Modelle, Macros, Seeds)
    models/
      bronze/              ← Source-System-Dispatch
      silver/              ← Validierung
      gold/                ← Konsumvertrag
    macros/
      source_system_columns.sql   ← Spaltenzuordnungen pro Quellsystem
  scripts/                 ← Extraktions-, Generierungsskripte
  glossary/                ← Registry-Glossar

3. Pack-Manifest erstellen

Erstelle jinflow.yml im Pack-Root:

pack_id: mypack
display_name: "My Analytics Pack"
brand: "My Pack"
description: "Analytical framework for [your industry]"
source_systems: [system_a, system_b]
branding:
  primary_color: "#3b82f6"
  tagline: "Every [thing] tells a story"

4. Aus deinem Tenant extrahieren

Der schnellste Weg ein Pack zu erstellen ist die Extraktion aus einem funktionierenden Tenant-AFS:

~/.jinflow/live/mypack/first_client/afs/

# Dein Tenant-AFS ist unter:
# Framework-Dateien kopieren (nicht Tenant-spezifische Daten)
mkdir -p ~/jinflow-packs/jinflow-pack-mypack
cd ~/.jinflow/live/mypack/first_client/afs

# Instrument-Definitionen kopieren
cp -r entities/ contracts/ probes/ hypotheses/ diagnoses/ \
      smebits/ bitbundles/ reports/ lineage/ glossary/ \
      ~/jinflow-packs/jinflow-pack-mypack/

# dbt-Projekt kopieren
cp -r dbt/ ~/jinflow-packs/jinflow-pack-mypack/

# Skripte kopieren
cp -r scripts/ ~/jinflow-packs/jinflow-pack-mypack/

# Manifest kopieren (pack_id bearbeiten und Tenant-spezifische Felder entfernen)
cp jinflow.yml ~/jinflow-packs/jinflow-pack-mypack/

5. Tenant-spezifischen Inhalt bereinigen

Pack bearbeiten um Tenant-spezifische Referenzen zu entfernen:

• SMEbits: alle mit scope.tenant_id auf einen bestimmten Tenant gesetzt entfernen (Cross-Tenant mit tenant_id: "*" oder null behalten)
• jinflow.yml: tenant, display_name, dlz_root entfernen — nur Pack-Level-Felder behalten
• Skripte: sicherstellen dass Extraktionsskripte mit den Daten jedes Tenants funktionieren

6. Git initialisieren

cd ~/jinflow-packs/jinflow-pack-mypack
git init
git add -A
git commit -m "feat: initial domain pack from first_client"

Optional zu GitHub pushen:

git remote add origin https://github.com/org/jinflow-pack-mypack.git
git push -u origin main

7. jinflow konfigurieren um das Pack zu finden

jinflow us --pack-root ~/jinflow-packs

Jetzt findet jinflow init --pack mypack dein Pack.

8. Einen zweiten Tenant erstellen

jinflow init --pack mypack --tenant second_client --source-system system_a \
  --dlzroot ~/jinflow-datalandingzone \
  --display-name "Second Client"

Dies kopiert das gesamte Pack-Framework in eine neue Tenant-Instanz. Lege die Daten des zweiten Kunden in die DLZ und baue:

jinflow make --tenant mypack.second_client --sync
jinflow explore --tenant mypack.second_client

Dieselben Signals, Theses und Verdicts laufen jetzt auf voellig anderen Daten. Findings werden sich unterscheiden — das Framework ist dasselbe, die Erkenntnisse sind kundenspezifisch.

9. Pack und Tenants synchron halten

Wenn du das Pack verbesserst (neue Signals, aktualisierte Theses):

# Alle Tenants vom Pack aktualisieren
jinflow afs update --all --do-it

# Oder einen Tenant nach dem anderen
jinflow afs update --tenant mypack.second_client --do-it

Three-Way-Sync stellt sicher, dass Tenant-spezifische Anpassungen erhalten bleiben. Nur Pack-Aenderungen werden angewandt; Konflikte werden markiert, nie stillschweigend ueberschrieben.

10. Der Pack-Lebenszyklus

Framework fuer Kunde A bauen
    ↓
In Domain Pack extrahieren
    ↓
Tenant fuer Kunde B aus Pack erstellen
    ↓
Kunde B Findings offenbaren neue Muster
    ↓
Neue Signals/Theses zum Pack hinzufuegen
    ↓
Verbesserungen zurueck an Kunde A synchronisieren
    ↓
Beide Kunden profitieren von gemeinsamen Lernerfahrungen

Das ist das Schwungrad: jeder neue Kunde macht das Framework besser, und jede Verbesserung fliesst an bestehende Kunden zurueck.

Was du gelernt hast

• Ein Domain Pack ist ein Git-Repo mit Instrumenten, Contracts, dbt-Modellen und Macros
• Aus einem funktionierenden Tenant extrahieren ist der schnellste Weg ein Pack zu erstellen
• jinflow init --pack kopiert das Framework in einen neuen Tenant
• jinflow afs update synchronisiert Pack-Verbesserungen an Tenants (Three-Way-Merge)
• Packs sind optional — du kannst immer ohne sie arbeiten
• Der Wert ist Wiederverwendung: einmal bauen, vielfach einsetzen, kontinuierlich verbessern

Naechste Schritte

• Domain Packs — detaillierte Dokumentation aller 4 ausgelieferten Packs
• Collaboration Guide — Git-Workflows fuer Pack- und Tenant-Verwaltung
• Tenants Guide — Multi-Tenant-Architektur
• Glossar — jeder Begriff erklaert