Spring Boot, PostgreSQL und Datenbankzugriff

In diesem dritten Teil von Block 2 wechselst du von SQL im Datenbankclient zu SQL als Teil einer Backend-Anwendung. Das Ziel ist nicht, Spring Boot als Framework auswendig zu lernen. Du sollst verstehen, wie eine Anwendung mit PostgreSQL verbunden ist und welche Verantwortung die einzelnen Schichten übernehmen.

Aus dem ersten Teil von Block 2 kennst du die ORM-Grundidee und die JPA/Hibernate-Einrichtung des Projekts. Aus dem zweiten Teil kennst du Flyway als Werkzeug für kontrollierte Schema Evolution. Jetzt zoomen wir heraus und verfolgen, wie pom.xml, application.yml, Migration, TicketEntity und TicketRepository im Request-Ablauf mit Controller, Service, Mapper und PostgreSQL zusammenspielen.

Wir arbeiten weiter mit dem Starterprojekt db-2-app. Es basiert didaktisch auf der Layer-Struktur aus dem bestehenden ORM-Lernprojekt, wurde aber als eigene Ticket-System-Fallstudie für DB-2 angelegt. Technisch nutzt es Spring Boot 4.0.x, Maven und Java 24; Spring Boot 4.0 wurde am 20. November 2025 veröffentlicht und baut auf Spring Framework 7 auf Webb (2025). Die aktuelle Spring-Boot-Dokumentation führt die 4.0.x-Linie als stabile Version VMware, Inc. (2026).

Das Projekt ist bewusst klein und nicht fertig. Es startet, zeigt Controller, Service, Repository, Entity, DTO und Flyway-Migration, enthält aber gezielte Lücken in der Datenbanklogik. Diese Lücken sind kein Fehler im Material. Sie sind der Arbeitsauftrag.

Architekturüberblick¶

Das Starterprojekt trennt HTTP, Fachlogik und Datenzugriff bewusst in eigene Schichten. Diese Trennung ist kein Selbstzweck: Sie macht sichtbar, wo eine Entscheidung getroffen wird und wo sie nur technisch ausgeführt wird.

Der Controller nimmt HTTP-Daten entgegen und gibt HTTP-Antworten zurück. Der Service koordiniert fachliche Abläufe. Das Repository kapselt den Datenzugriff. Die Entity beschreibt, wie Java-Objekte auf Tabellen abgebildet werden. PostgreSQL speichert nicht nur Daten, sondern schützt fachliche Regeln durch Constraints.

Die wichtigste Frage für DB-2 lautet deshalb nicht nur: “Wo steht welcher Code?” Sondern: “Welche Regel gehört in welche Schicht?”

Vom Request zur Datenbank¶

Eine typische Anfrage läuft in dieser Reihenfolge durch die Anwendung:

Im Starterprojekt kannst du diesen Ablauf an GET /api/tickets?status=open nachvollziehen. Die Repository Method findByStatusOrderByCreatedAtDesc zeigt, wie Spring Data aus einer Methodensignatur eine parametrisierte Abfrage ableitet. Das Framework nimmt Schreibarbeit ab, aber die fachliche Entscheidung bleibt bei dir: Ist diese Abfrage noch verständlich? Welche Spalten und Constraints braucht die Tabelle? Welche Werte darf status annehmen?

Start und Datenbankmigration¶

Beim Start verbindet Spring Boot mehrere Bausteine: application.yml liefert die Datenbankkonfiguration, Flyway führt Migrationen aus, Hibernate/JPA prüft das Mapping, und erst danach ist die Anwendung sinnvoll benutzbar.

Diese Startreihenfolge ist didaktisch wichtig: Wenn die Migration eine Regel nicht enthält, kann der Anwendungscode diese Lücke zwar teilweise kaschieren, aber PostgreSQL schützt die Daten dann nicht selbst.

Guided Gaps¶

Die erste Flyway-Migration im Starterprojekt erstellt eine absichtlich schwache Tabelle. Sie enthält ein minimales tickets-Schema, aber noch keine ausreichenden Pflichtfelder und keine Status-Constraint. Damit wird sichtbar, warum Datenbankentwicklung mehr ist als API-Validierung:

• Eine API kann Eingaben prüfen.

• Ein Service kann fachliche Abläufe koordinieren.

• Die Datenbank muss zentrale Invarianten trotzdem selbst schützen.

Die aktivierbare Engineering-Aufgabe liegt im Starterprojekt:

./mvnw -Pguided-gaps test

Dieser Test schlägt am Anfang erwartbar fehl. Er wird erst grün, wenn du eine neue Flyway-Migration schreibst, zum Beispiel:

src/main/resources/db/migration/V2__enforce_ticket_rules.sql

Du änderst dafür nicht V1__starter_ticket_schema.sql. V1 steht für den bereits gelaufenen Startzustand. V2 beschreibt den nächsten Entwicklungsschritt und sorgt dafür, dass PostgreSQL grundlegende Ticket-Regeln erzwingt.

Unterrichtsstruktur¶

1. Architekturüberblick: Spring Boot, PostgreSQL und Layered Architecture als Abschluss des Block-2-Fadens.

2. Datenbankkonfiguration, Repository-/Service-Zusammenspiel und sichere Parameter.

3. Guided Code Reading am Starterprojekt mit anschliessender Aufgabe zu einer neuen Flyway-Migration.