4 · Lösungsstrategie¶
Die Lösungsstrategie beschreibt, mit welchen grundlegenden Entscheidungen die ODI ihre Qualitätsziele erreicht. Die sieben Prinzipien unten sind keine Wunschliste, sondern konkrete Leitlinien, die sich in der Codebasis und in den Deployment-Manifesten direkt wiederfinden.
Microservice-Architektur, capability-basiert¶
Jeder Dienst kapselt genau eine fachliche Fähigkeit – etwa „Schemas verwalten" (odi-schema-backend), „Daten validieren" (odi-frictionless-backend) oder „Katalog-Operationen ausführen" (odi-ckan-service). Dienste sind unabhängig entwickel- und deploybar; sie kommunizieren ausschließlich über HTTP-REST. Das erlaubt es, einzelne Dienste zu ersetzen, zu skalieren oder weiterzuentwickeln, ohne das Gesamtsystem anzufassen.
Die Orchestrierungsdienste (Staging-Backend, Geodaten-Dienst, Semantic-Data-Dienst) stehen dabei gleichrangig nebeneinander. Es gibt keinen zentralen Monolith, der alle Veröffentlichungswege steuert; jeder Orchestrierungsdienst ist für seinen Weg vollständig verantwortlich.
Backend-for-Frontend (BFF)¶
Das Frontend odi-schema-staging-frontend kennt die internen Dienste nicht direkt. Es spricht ausschließlich mit dem Staging-Backend, das als BFF alle erforderlichen Aufrufe bündelt, transformiert und absichert. Dadurch können Frontend und Backend unabhängig voneinander weiterentwickelt werden, und die interne Servicestruktur bleibt nach außen verborgen.
Hexagonale Architektur¶
Innerhalb jedes Dienstes ist die Fachlogik strikt von den technischen Adaptern getrennt. Externe Systeme – Datenkatalog, Schema-Repository, Frictionless-Validierung – werden nicht direkt aufgerufen, sondern über austauschbare Client-Adapter angebunden. Das deutlichste Beispiel ist der odi-ckan-service: Er ist eine Fassade, die das Staging-Backend vom konkreten Datenkatalog (CKAN oder Piveau) entkoppelt. Ein Katalog-Wechsel erfordert nur Änderungen am Adapter, nicht an der Fachlogik.
Cloud-Native nach 12-Factor¶
Alle Dienste sind zustandslos und containerisiert. Konfiguration kommt ausschließlich aus Umgebungsvariablen – kein hart codierter Hostname, kein hardcodiertes Secret. Das macht jeden Dienst in beliebigen Umgebungen (lokal per Docker Compose, Stage, Produktion) ohne Code-Änderungen startbar. Lokal startet die gesamte Plattform per docker compose up aus odi-docker-compose-deployment.
Stabilität über Referenzen¶
Datensätze referenzieren Schemas, Lizenzen, Publisher, Kategorien und Raumbezüge über stabile IDs, nicht über eingebettete Kopien. Ändert sich beispielsweise der Name einer Lizenz im Metadaten-Dienst, bleiben alle Datensätze, die diese Lizenz-ID tragen, korrekt verknüpft. Das odi-metadata-service-Repository liefert die kanonischen DCAT-AP-konformen IDs für alle diese Referenzdaten.
Abwärtskompatible APIs¶
Schnittstellen werden versioniert und so weiterentwickelt, dass bestehende Integrationen – Fachverfahren, Skripte, Drittportale – ohne Anpassung weiter funktionieren. Bricht eine Änderung die Rückwärtskompatibilität, erhält sie eine neue Versionsnummer. Das betrifft insbesondere das Staging-Backend (staging-backend.odi.schleswig-holstein.de) und das Schema-Repository (schema-repo-backend.odi.schleswig-holstein.de).
Permissions statt Rollen¶
Zugriffe werden über feingranulare Berechtigungen im JWT gesteuert, nicht über grobe Rollen wie „Admin" oder „User". Ein JWT-Claim kann zum Beispiel das Recht enthalten, Datensätze in einem bestimmten Katalog zu veröffentlichen, nicht aber in einem anderen. Dieses Modell macht die Autorisierung transparent und nachvollziehbar – wer welche Berechtigung hat, steht direkt im Token, nicht in einer zentralen Rollentabelle.