DI²

Data Integration²

ETL-Strecken aus Metadaten erzeugen - wartbar, lesbar, auditierbar.

Ein eigenes Projekt, von der Spec über die UX bis zum produktiven Deploy selbst gebaut. Diese Seite zeigt nicht nur, was DI² ist - sondern auch wie es entwickelt wird.

Was DI² in einer halben Minute ist

Vision, Output-Format, Methoden-Herkunft und Datenqualitäts-Philosophie - komprimiert auf vier Absätze.

DI² erzeugt wartbare, lesbare und auditierbare ETL-Prozesse aus den Metadaten deines Quellsystems - automatisch, in reinem SQL. Der Output läuft heute auf PostgreSQL und SQL Server.

Ausgangspunkt sind Tabellen, Spalten, Typen und Beziehungen - sie werden zum Modell, angereichert um fachliches Wissen wie zulässige Werte, Business Keys und Historisierungsregeln. Aus diesem Modell entstehen automatisch Extraktion und SCD2-Historisierung; die Transformation in DWH oder OLTP bleibt bewusst Handarbeit - DI² liefert das Gerüst, ihr schreibt die fachliche Logik.

Datenqualität ist das Produkt, nicht ein Feature. Fachliche Regeln als WHERE-Klauseln in den Metadaten; fehlerhafte Datensätze landen in einer Fehler-Tabelle statt still im DWH. Drei Protokoll-Ebenen - Prozess, Schritt, Stacktrace - auswertbar per SELECT.

Keine Neuerfindung: Die Methode existiert seit 2015 in ständiger Iteration - initial als VBA/Excel-basierter Codegenerator, heute als PostgreSQL-native Engine mit Next.js-Web-Layer. DI² ist die Re-Implementation einer über 10 Jahre erprobten Vorgehensweise auf modernem Stack.

Wie DI² Entscheidungen trifft

Jedes Tool macht Annahmen über das, was wichtig ist. Diese sind die unsrigen - explizit, damit sie diskutierbar bleiben.

01 · Vision

Reines SQL als Output

ETL-Prozesse automatisch aus Metadaten. Der erzeugte Code ist der Vertrag - versioniert, diffbar, ohne zusätzliche Abstraktionsschicht.

02 · Data-first

Tabellen statt Klicks

Der Prozess entsteht direkt aus Tabellen, Spalten, Typen, Beziehungen - datenmodell-getrieben statt klick-getrieben.

03 · Portabel

Zwei RDBMS heute, portierbar

Versioniertes SQL läuft heute auf PostgreSQL und SQL Server. Eine Portierung auf andere Dialekte (Snowflake, BigQuery, Oracle, DuckDB) ist überschaubar, weil der Output reines SQL bleibt.

04 · Wartbar

Jede Prozedur eine Datei

Jeder Code-Change als Git-Diff sichtbar. Reines SQL ohne DSL - Engineers und Analysten verstehen es ohne Einarbeitung.

05 · Auswertbar

Jeder Lauf belegbar

Drei Protokoll-Ebenen - Prozess, Schritt, Stacktrace - alles auswertbar per SELECT. Nicht spürbar, sondern messbar.

06 · Fachwissen

Regeln werden Metadaten

Zulässige Werte, Wertebereiche, Business und Alternate Keys, Historisierungsregeln leben im Modell - nicht als Kommentare im Code.

07 · Stages

Drei generierte Stages

Extraktion und SCD2-Historisierung werden automatisch erzeugt; die DWH/OLTP-Transformation bleibt Handarbeit - bewusst.

08 · DQ

Qualität ist das Produkt

Fachliche Regeln als WHERE-Klauseln. Fehlerhafte Datensätze landen in einer Fehler-Tabelle - nicht still im DWH.

Fünf Schritte

Von Metadaten zur Produktion

01
Quelle anbinden
MSSQL · PostgreSQL · MySQL
02
Schema scannen
information_schema
03
Anreichern
BK · DQ · Historisierung
04
SQL generieren
DDL · Staging · SCD2
05
Orchestrieren
SQL synchron · Python async

Vier Environments, ein VPS, eigene Identity

Self-hosted auf Hetzner (EU-Rechenzentrum, Deutschland) - kein Vercel, kein Supabase, kein US-Managed-Service für sensible Layer. Daten-, Auth- und Mail-Stack durchgängig im EU-Raum, DSGVO-konform. Docker Compose mit Multi-App-Layout, Nginx als Reverse Proxy, Let's Encrypt für SSL.

Browser

HTTPS

All-Inkl DNS

A-Record → VPS

GitHub Actions

SSH Deploy

↓ ↓ ↓

Hetzner Cloud VPS

Docker Compose · Multi-App-Layout · /home/fupi/app/di2/<env>

Nginx Reverse Proxy · Let's Encrypt SSL

Application

Next.js DEV

:3000

Application

Next.js INT

:3001

Application

Next.js TEST

:3002

LIVE

Application

Next.js PROD

:3003

PostgreSQL 17

di2_postgres

App-Daten · Audit · Stored Procedures
Self-hosted · pg-Client mit Connection-Pooling

Keycloak 26

di_keycloak

OIDC IdP · eigene Postgres-Instanz · Custom Theme
Auth.js v5 · JWT-Sessions (8h) · rollenbasiert

Stack

Next.js 16 / React 19 / TypeScript
PostgreSQL 17 (self-hosted)
Tailwind 3 + shadcn/ui
Auth.js v5 (NextAuth) + Keycloak OIDC

Auth & Identity

Keycloak als zentraler IdP
JWT-Sessions (8h), rollenbasiert
Lokaler User-Schatten + Reconcile-Job
Custom Theme (DI²) für Login & Mails

CI/CD

GitHub Actions → SSH → Hetzner
4 Environments parallel auf 1 VPS
schema_apply_log Audit-Trail
Security-Gate vor Prod-Deploy

Acht Phasen, ein Skill pro Phase, Human-in-the-Loop

AI-driven Development heißt nicht „Claude schreibt allein Code“. Es heißt: spezialisierte Skills pro Workflow-Schritt, klare Checkpoints, und an jeder Phase wartet das System auf eine Entscheidung.

1Spec
2Design
3UX
4Backend
5Frontend
6Test
7Review
8Deploy
9Audit

Phase 1 · Spec

Requirements

/requirements

Feature-Spec mit User Stories, Acceptance Criteria, Edge Cases - und der Markierung, was nur am Klick prüfbar ist.

Phase 2 · Design

Architecture

/architecture

Technische Architektur, PM-tauglich, ohne Code.

Phase 3 · UX

UX & Mockups

/ux

UX-Kritik + Mockups (HTML / React + shadcn) als Vorlage - dazu die Klick-Testfälle, bevor gebaut wird.

Phase 4 · Build

Backend

/backend

API-Routen, DB-Schema, Stored Procedures, RLS-Policies.

Phase 4 · Build

Frontend

/frontend

UI mit shadcn/ui - gegen echte APIs, keine Mocks.

Phase 5 · Test

QA

/qa

Fährt die deklarierten Testfälle und protokolliert den Lauf. Acceptance + Edge Cases + feature-scoped Security-Checks.

Phase 6 · Review

Code Review

/review

Diff gegen Spec & Conventions; Approve / Request Changes.

Phase 7 · Deploy

Deploy

/deploy <env>

GitHub Actions: dev → int → test → prod, jede Stufe mit Gate - rote Tests heißen: kein Deploy.

Phase 8 · Audit

Security

/security

Pflicht-Gate vor prod: OWASP, Auth, Headers, Dependencies.

Cross-cutting · Always-on

Skills, die quer zum Workflow laufen

Bug-Loop

/bug - docs/bugs/bug-NNNN-<slug>.md

Jederzeit triggerbar - Doku, gezielter Fix, QA-Re-Test, Close. Bugs werden nie reopened; Regression bekommt neue ID.

Maintenance-Checks

/check-updates · npm · Docker · Actions · VPS

Periodische Wartung: Dev-Dependencies und VPS-Komponenten - read-only Befunde, kein Auto-Apply.

Zwei Test-Netze, ein Katalog, die Erwartung vor dem Code

AI-driven Development steht im Verdacht, Tests als Erstes zu streichen. Hier steht, was geprüft wird, wie es geprüft wird und wann die Erwartung festgelegt ist.

Zwei Netze

Automatisiert, was sich rechnen lässt - geklickt, was nur am Bildschirm sichtbar wird

Automatisiert

Vitest · Unit- und Komponenten-Tests

Logik mit Verzweigungen, Validierung, Sortierung, Texte je Sprache. Die Tests liegen direkt neben dem Code, den sie prüfen, und wandern bei jedem Umbau mit.

Manuell

docs/test-cases · Klick-Testfälle

Nur, was sich nicht rechnen lässt: das Zusammenspiel mehrerer Ansichten, der Zeitpunkt, zu dem ein Ergebnis sichtbar wird, Meldungen, Anmeldung und Abmeldung.

Rot heißt: kein DeployBei jedem Push laufen Lint, Konventions-Prüfungen, Tests und Build. Vor jedem Deploy laufen die Tests ein zweites Mal - schlagen sie fehl oder fehlt eine Testdatei im Lauf, startet der Deploy nicht.

Der Katalog

Testfälle als eigene Achse neben Features und Bugs

Der Katalog umfasst 158 aktive Testfälle in 22 Suiten. Jeder ist so geschrieben, dass ihn jemand abarbeiten kann, der den Code nie gesehen hat.

TEST-NNNN: Dritte Kennung neben diapp-NNNN für Features und BUG-NNNN für Bugs. Ein Testfall behält seine Nummer und seinen Ablageort für immer.
Deklaration ≠ Protokoll: Der Testfall beschreibt Schritte und erwartetes Ergebnis. Was bei einem Lauf herauskam, steht in einem eigenen Protokoll - ein Ergebnis in der Testfall-Datei würde den nächsten Lauf entwerten.
Suiten: Eine Suite ist, was in einer Sitzung auf demselben Ausgangszustand durchgeklickt wird. Ein Testfall darf mehreren angehören.
Abdeckung: Jeder Testfall nennt die Dateien, auf die er zielt. Welche Fälle nach einer Änderung fällig sind, ergibt sich damit aus dem Diff - nicht aus dem Gedächtnis.
Lauf-Klassen: Smoke läuft bei jedem Deployment. Regression läuft, wenn die Abdeckung getroffen ist, und vollständig vor jedem Prod-Deploy.

Die naheliegende Kritik

Wer prüft, wenn dieselbe Instanz Spec, Code und Test schreibt?

In der klassischen Aufstellung verhindert die Trennung von Tester und Entwickler, dass ein Test an der fertigen Implementierung entlang geschrieben wird. Bei AI-driven Development gibt es diese Trennung nicht. Sie wird deshalb zeitlich hergestellt statt personell.

Erwartung/requirements
Das erwartete Ergebnis steht als Acceptance Criterion in der Spec - bevor eine Zeile Code existiert.
Testfall/ux
Der Testfall übernimmt diese Erwartung wörtlich und ergänzt die Klick-Schritte aus den Mockups. Erst danach beginnt der Bau.
Lauf/qa
Nach dem Bau wird der Fall gefahren und protokolliert. Weicht das Ergebnis ab, ist das ein Befund - die Erwartung wird nicht nachgezogen.

Zwei Schreibregeln halten die Trennung fest: Im erwarteten Ergebnis steht kein Begriff, der nicht auf dem Bildschirm vorkommt. Und jeder Testfall enthält mindestens eine Aussage darüber, was nicht passieren darf.

Auch dieser Abschnitt ist so entstanden: seine Testfälle standen im Katalog, bevor er gebaut wurde.

Kontakt

E-Mail LinkedIn XING