Master 22 - Database, Migration & Persistence Master - Beschreibung
Master 22 - Database, Migration & Persistence Master - große Erklärung
Ziel
Postgresql-schemas, migrationen, demo-daten, outbox, audit und legacy-datenmigration.
Warum das nach Master 20 sinnvoll ist
Master 1 bis 20 liefern Fachsysteme, Infrastruktur, Tests, CI/CD und Operations. Master 22 konkretisiert einen nächsten Reifegrad: mehr Bedienbarkeit, mehr Datenrealismus, mehr Frontend oder mehr Modernisierungstiefe.
Konkreter Ablauf
1. Schema planen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
2. Migration ausführen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
3. Demo-Daten laden - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
4. Outbox schreiben - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
5. Audit prüfen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
6. Backup simulieren - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
7. Restore simulieren - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
Architekturgedanke
Die Module sind bewusst klein gehalten. Jedes Modul hat eine klare Aufgabe. Die Abhängigkeiten sollen nach innen zeigen; Infrastruktur bleibt austauschbar. Dadurch bleiben Refactoring, Tests und Migration möglich.
Verwendete Entwurfsmuster
• Command: Schritte sind ausführbare Aktionen.
• Pipeline: Fachliche Abläufe werden nachvollziehbar verkettet.
• Adapter: Externe Systeme werden über klare Schnittstellen angebunden.
• Facade: Das Portal oder Gateway bietet einen einfachen Einstieg.
• Strategy: Infrastruktur- und Fachvarianten bleiben austauschbar.
• Result Object: Ergebnisse werden explizit statt implizit behandelt.
Submodule und Tests
| Modul | Aufgabe | Pattern | Tests | |
|---|---|---|---|---|
db-model-common | Gemeinsames Modell für Tabellen (TableDefinition) und Spalten (ColumnDefinition) aller Fachschemas. | Value Object | TableDefinitionTest (2): erkennt vorhandene/fehlende Spalte, lehnt Tabelle ohne Spalten ab. | |
flyway-plan | Erzwingt lücken- und duplikatfreie Migrationsversionen; SchemaMigration (Domain) haelt den erreichten Schema-Stand, SchemaExecutor-Port trennt Migrationslogik von der DB-Anbindung, MigrationRunner (Application) orchestriert alles. | Ordnen -> ueber Port ausfuehren -> Schema-Stand fortschreiben | Ordered Pipeline, Aggregate, Port/Adapter, Application Service | FlywayPlanTest (2). SchemaMigrationTest (2): wendet Skripte in Reihenfolge an, lehnt uebersprungene Version ab. MigrationRunnerTest (1): wendet alle Skripte ueber den Executor-Port in Reihenfolge an. |
insurance-schema | Baut die Policy-Tabelle mit den fachlich verpflichtenden Spalten. | Factory | InsuranceSchemaTest (1): enthält policy_id und premium. | |
banking-ledger-schema | Baut die Ledger-Tabelle mit den fachlich verpflichtenden Spalten. | Factory | BankingLedgerSchemaTest (1): enthält account_id und amount. | |
erp-schema | Baut die Invoice-Tabelle mit den fachlich verpflichtenden Spalten. | Factory | ErpSchemaTest (1): enthält vendor_id und total_amount. | |
healthcare-schema | Baut die Visit-Tabelle mit den fachlich verpflichtenden Spalten. | Factory | HealthcareSchemaTest (1): enthält patient_id und copay. | |
legacy-source-schema | Bildet die alte Legacy-Tabellenform ab, bevor sie migriert wird. | Factory | LegacySourceSchemaTest (1): enthält legacy_id und raw_payload. | |
outbox-audit-schema | Outbox-Tabelle plus Versand-Logik: Änderung und Event-Versand teilen dieselbe Transaktion. | Transactional Outbox | OutboxAuditSchemaTest (2): versendet ausstehenden Eintrag, lehnt Doppelversand ab. | |
backup-restore-lab | Prüft, ob ein wiederhergestellter Snapshot alle erwarteten Tabellen enthält. | SRE Restore Drill | RestoreDrillTest (2): meldet keine Lücke bei vollständigem Restore, nennt fehlende Tabelle. | |
runnable-smoke | Verdrahtet alle Schemas, den Migrationsplan, die Outbox und das Restore-Lab zu einem End-to-End-Lauf (mvn -pl runnable-smoke -am package). | Command, Pipeline, Result Object | Kein eigener JUnit-Test; verifiziert STATUS=OK für alle sechs Schritte zur Laufzeit und bricht mit Fehler ab, falls einer abweicht. |
Ausbaustufe 1 (minimal lauffähig): 13 JUnit-Tests über 9 vormals leere Submodule. Ausbaustufe 2 (fachlich ausgearbeitet): flyway-plan bekam das SchemaMigration-Aggregat, den SchemaExecutor-Port (austauschbar gegen eine echte JDBC-Anbindung) und den MigrationRunner — 3 weitere Tests, macht 16 Tests insgesamt für dieses Modul. Verifiziert mit mvn test (alle grün) und dem End-to-End-Smoke-Lauf mvn -pl runnable-smoke -am package (weiterhin STATUS=OK: 6 Tabellen geplant, 6 Migrationsskripte über den Schema-Executor-Port angewendet, Outbox-Event versendet, Restore vollständig).