Code-Snippets

Nach dem Auspacken siehst du sowas:

Die Entry-Point-Datei sieht so aus:

Lies das gleich richtig:

Über Spring Initializr per curl (geht ohne Browser, ohne lokales

projekt/src/main/kotlin/com/example/hello/HelloController.kt

mitzumachen reicht, damit dir die Begriffe in Lektion 02 (Annotations, Generics, Lambdas, Streams) nicht um die Ohren

zu viele Imports zusammenkommen — bleib bei expliziten Imports.

nützlich für interne Helper, kann aber überraschen, wenn man damit nicht rechnet.

Template-Method-Patterns).

final hat drei Bedeutungen, je nachdem, vor was es steht:

Ein typisches Klausur-Beispiel; in echtem Spring-Code praktisch nicht nötig:

Java konvertiert automatisch zwischen int und Integer (und allen anderen Paaren):

StringBuilder ist die mutable Alternative für Hot-Loops.

false, wenn die Argumente unterschiedlich sind oder nur eines null ist, ohne dass dir die NPE um die Ohren fliegt.

Java erlaubt mehrere Konstruktoren mit unterschiedlichen Parameterlisten in derselben Klasse:

PHP-Constructor-Promotion + readonly.

Klassen, von denen du nicht direkt eine Instanz bauen kannst — nur Subklassen:

richtige provider()-Implementierung. Wie in PHP, nur strenger typisiert.

Wenn du semantische Gleichheit willst (gleiche E-Mail = gleicher User), überschreibst du equals:

und der Unterschied wird vom Compiler erzwungen:

Hierarchie ist ein Beispiel — die JDBC-SQLException (checked) wird in eine RuntimeException umgewickelt.

Spring-Code.

try-Blocks automatisch. Ein Pendant in PHP gibt es nicht; dort musst du finally { fclose($f); } schreiben.

Behandlung kommt in B1/L05–L10.

Kotlin kennt zwei idiomatischere Wege:

Kotlin: gleiches Konzept, aber kompakter:

src/com/example/shop/Address.java:

src/com/example/shop/User.java:

src/com/example/shop/AdminUser.java:

src/com/example/shop/App.java:

Output (in der Reihenfolge der println-Aufrufe):

Compiler, eine IDE, ein Framework wie Spring).

Hibernate-Universum ist darauf aufgebaut.

FIELD, METHOD, PARAMETER, CONSTRUCTOR. Du kannst mehrere kombinieren: @Target({TYPE, METHOD}).

intern definiert als:

in modernen Tools. Generics in Java sind dasselbe Konzept, aber vom Compiler erzwungen.

Mehrere Parameter:

Eine Methode kann ihren eigenen Typ-Parameter haben — unabhängig von der Klasse:

Manchmal willst du den Typ einschränken: „T muss Comparable sein."

Oder „eine Liste, deren Elemente von Number erben" — sinnvoll, wenn du nur lesend zugreifst:

mit Erasure.

≤ 7) hat man so etwas immer als anonyme Klasse geschrieben:

(parameters) -> { statements; }

(nach der Initialisierung nicht mehr zugewiesen werden):

genau das, was du in Laravel mit Collections machst:

Drei Phasen:

Wenn du dieselbe Pipeline zweimal brauchst, bau sie zweimal — oder leg das Zwischenergebnis als List ab.

IntStream, LongStream, DoubleStream sind spezialisierte Streams für Primitive — kein Boxing, schneller:

Ergebnis fehlen kann (leerer Stream). Du arbeitest mit Optional wie folgt:

Wenn jede Element-Transformation mehrere neue Elemente erzeugt, brauchst du flatMap:

Damit du eine Vorahnung hast, wie diese vier Bausteine in Phase 2 zusammenspielen:

Kotlin hat zwei Wege:

src/com/example/audit/Audit.java:

src/com/example/orders/Order.java:

src/com/example/orders/OrderStats.java:

src/com/example/orders/OrdersDemo.java:

Streams-Ergebnisse mit For-Loop-Ergebnissen — sie müssen identisch sein.

Eine typische DTO-Klasse in „klassischem" Java sieht so aus:

PHP-Vergleich:

Records sind keine Datenkonserven. Du kannst Methoden hinzufügen:

Normalisierung:

das ist auch erlaubt, aber selten nötig.

interfaces (siehe Sektion 7).

javap -p UserDto.class zeigt dir ungefähr:

Optional<String> maybe = Optional.ofNullable(possiblyNullVar);

Vorher (switch-Statement):

Mit Block-Body und yield für Mehr-Zeilen-Logik:

Seit Java 21 final:

prüft der Compiler auf Vollständigkeit — du kannst keinen Case vergessen.

Endlich null im switch ohne separaten if-Check davor.

Keine Suche nach „wer erbt von X" — der Header sagt's.

static <T, E> Result<T, E> err(E error) { return new Err<>(error); }

Mit Text Blocks (Java 15 final):

Praktische Anwendung:

Damit du das Zusammenspiel einmal komplett siehst, hier ein realistischer Mini-Domainblock, der alle Features

return unitPrice.multiply(BigDecimal.valueOf(quantity));

beides funktioniert in Records nicht direkt. Volle Lehre in B1/L07.

Immutability sichtbar.

default -> "unbekannt";

Layout nach diesem Schritt:

Öffne src/com/example/orders/Order.java und ersetze die klassische Klasse durch:

Validiere mit einem Aufruf:

src/com/example/result/Result.java:

src/com/example/payments/PaymentEvent.java:

src/com/example/payments/CardEvent.java:

src/com/example/payments/BankEvent.java:

src/com/example/payments/CashEvent.java:

src/com/example/payments/RefundEvent.java:

src/com/example/payments/PaymentEventHandler.java:

src/com/example/payments/PaymentDemo.java:

die Lektion verstanden.

In Java schreibst du Felder und Accessors selbst:

schreibst du Custom Accessors:

In Java schreibst du den Konstruktor separat:

Wenn die Klasse einen Body braucht, hängst du ihn dran:

Berechnungen. Dafür gibt es den init-Block:

Java verlangt für jede Funktion eine Klasse:

Kotlin erlaubt dir, Funktionen direkt am Datei-Top zu definieren:

Konstanten und Konfiguration-Werte landen genauso am Top:

3. Bestehende Java-APIs Kotlin-idiomatisch nutzen. Du kannst der Java-Klasse java.time.LocalDate eine Extension isWorkday() hinzufügen, ohne die Klasse zu kennen oder modifizieren zu können.

und Builder-Pattern. Kotlin löst es mit Default-Werten am Parameter:

benennen. Beispiel:

build.gradle.kts:

sie ist nur der Maßstab, gegen den deine Kotlin-Variante steht:

strings.kt — Top-Level-Funktionen:

stringextensions.kt — dieselben drei Funktionen als Extensions:

Main.kt — die fun main(), die alles ausprobiert:

Extension-Aufruf:

Workaround: lokale val zwischenspeichern.

Hauptanwendung: ein Objekt initialisieren und einen Wert daraus

Wie sieht das in einer kleinen, realistischen Funktion zusammen aus?

build.gradle.kts:

src/main/kotlin/Profile.kt:

src/main/kotlin/Main.kt:

konfiguriere sie idiomatisch:

Tippe src/main/kotlin/Animal.kt:

beim Pattern Matching prüfen, ob du alle Fälle abgedeckt hast.

idiomatische Weg:

Kotlin macht das mit einem Schlüsselwort:

schreibst du companion object innerhalb der Klasse:

mächtiger. Drei Modi.

exhaustive ist (Int ist nicht sealed).

Cast (siehe B1/L06) angewendet auf sealed Hierarchien.

Wie sieht das in einem realistischen Mini-Modell aus?

build.gradle.kts:

Tippe src/main/kotlin/Result.kt:

Tippe src/main/kotlin/Money.kt:

Tippe src/main/kotlin/Cart.kt:

Tippe src/main/kotlin/Main.kt:

Innerhalb eines Scopes gibt es zwei Wege, eine Coroutine zu starten.

Scope wartet implizit auf alle Children, bevor er endet.

Children fertig sind.

manuelle Cleanup-Logik schreiben:

nicht mitnimmt. Dann nimmst du supervisorScope:

Wie sieht das in einer realistischen Funktion aus?

build.gradle.kts:

Tippe src/main/kotlin/Main.kt:

ersetze die obige Funktion zeitweise):

Unterschied:

Dispatchers.IO umgeleitet wird:

Bau ein finales Main.kt, das alles kombiniert:

aus Gradle KTS, das du in jeder Buch-2-Lektion sehen wirst:

entsteht das, was wie eine Block-DSL aussieht:

Die Scope-Functions aus B1/L06 sind Standard-Library-DSL-Funktionen:

Tags, body und h1, plus Text-Inhalten:

html.block()

den Receiver von außen sichtbar hält:

anderen Marker-Receiver vom Compiler ausgeblendet.

ein Kotlin-Projekt generiert:

Spring Security in Boot 4 bringt eine Kotlin-DSL mit. Sie sieht so aus:

verschachtelte Block-Struktur geschrieben:

build.gradle.kts:

Tippe src/main/kotlin/HtmlDsl.kt:

Tippe src/main/kotlin/Main.kt:

Versuche bewusst, eine ungültige Verschachtelung zu tippen:

oder generiere ein neues mit:

Beispiel-Struktur:

Boot-4-Kotlin-Projekt mit Web + DevTools generiert (gekürzt):

Methoden standardmäßig final — Subklasse-Bilden scheitert.

Reflection-basiertes Instanziieren).

KSerializer-Implementierungen für @Serializable-Klassen generiert.

4 wird es Standard.

So aktiviert man KSP für ein Projekt:

Ein Version Catalog liegt unter gradle/libs.versions.toml:

Im build.gradle.kts referenzierst du dann typsicher:

Inhalt eines Convention Plugins (kotlin-spring-conventions.gradle.kts):

In einem Subproject-build.gradle.kts:

Hole dir einen sauberen Stand zum Spielen:

schon im Projekt vom Gradle-Wrapper):

Ersetze den plugins-Block:

Und den dependencies-Block:

build-logic/build.gradle.kts:

build-logic/src/main/kotlin/kotlin-spring-conventions.gradle.kts:

referenzieren:

Jetzt das Haupt-build.gradle.kts umstellen — der Plugin-Block schrumpft

koin-demo/build.gradle.kts:

src/main/kotlin/Main.kt:

Du hast die Annotation in Buch 1 / Lektion 01 schon gesehen — hier in der Kotlin-Variante, die Boot 4 als Default ausgibt:

@SpringBootApplication ist eine Meta-Annotation — sie kombiniert drei einzelne Annotations. Wenn du die Source-Datei aufmachst (in IntelliJ: Cmd+Click auf die Annotation), siehst du im Wesentlichen:

spring-boot-starter-web ist ein Starter — eine Meta-Dependency, die selbst keinen ausführbaren Code enthält, aber über transitive Dependencies einen aufeinander abgestimmten Stack mitbringt. Wenn du ./gradlew dependencie

In build.gradle.kts steht oben:

Das ist eine schlichte Textdatei mit einem voll qualifizierten Klassennamen pro Zeile. Beispiel-Inhalt aus spring-boot-autoconfigure:

Jede Auto-Configuration-Klasse ist eine ganz normale @Configuration-Klasse, hat aber zusätzlich @Conditional…-Annotations darauf, die entscheiden, ob sie aktiviert wird. Ein gekürztes Beispiel aus dem Spring-Source-Code:

Viele Auto-Configurations haben @EnableConfigurationProperties(XxxProperties.class). Die XxxProperties-Klasse ist eine annotierte POJO, deren Felder aus application.yml/application.properties befüllt werden. Beispiel:

Der Output sieht so aus:

application.yml (YAML, hierarchisch):

Beim Start druckt Spring Boot dieses ASCII-Art-Banner:

Tomcat ist Default. Wechseln auf Jetty: In build.gradle.kts Tomcat ausschließen, Jetty einziehen:

Wichtige Server-Properties:

Das praktischste Beispiel ist Setup-Code, der einmal beim Start laufen soll. Eine Bean, die CommandLineRunner implementiert, bekommt die Command-Line-Argumente und wird genau einmal nach Context-Refresh ausgeführt:

Speichere dir 5 bis 10 Zeilen aus dem Report als Kommentar oben in einer neuen Datei projekt/src/main/resources/AUTOCONFIG-NOTES.md (Markdown — nicht versionsrelevant, dient nur als Lern-Notiz). Beispiel:

Lege folgendes File an: projekt/src/main/resources/banner.txt

Im Generator wurde application.properties angelegt. Wir machen daraus YAML.

Lege ein zweites Property-File an: projekt/src/main/resources/application-dev.yml

Erweitere application.yml (NICHT die application-dev.yml):

Anschließend startest du die App dreimal und beobachtest das Verhalten:

Lege folgende Klasse an: projekt/src/main/kotlin/com/example/hello/StartupReporter.kt

Laravel-Brücke. Du kennst das Pattern bereits, ohne den Namen unbedingt zu nutzen:

Spring macht das Gleiche. Andere Annotation-Namen, andere Sprache, identisches Pattern — und in Kotlin schrumpft die Klasse auf eine Zeile:

Springs IoC-Container heißt ApplicationContext. Stell ihn dir vor als eine Map<Klasse, Objekt> mit zusätzlichem Lebenszyklus-Management. Beim Start sammelt er Bean-Definitions, instanziiert sie, verdrahtet sie miteinande

Weg B — @Bean-Methode in einer @Configuration-Klasse:

Beispiel der Package-Layout-Regel:

Field-Injection war in Spring 3/4 verbreitet und sieht in alten Tutorials oft so aus. Schreib heute keine neue Klasse mit Field-Injection — und in Kotlin verbietet sich das lateinit-Pattern doppelt, weil es das Idiom „ei

Was, wenn es zwei Beans desselben Typs gibt? Beispiel: zwei GreetingService-Implementationen.

Der Qualifier-Name ist standardmäßig der Klassenname mit kleinem Anfangsbuchstaben (CasualGreetingService → casualGreetingService). Du kannst auch eigene Qualifier-Namen vergeben:

Wenn du eine semantisch starke Wahl willst, baust du dir eine eigene Annotation. In Kotlin sieht das so aus:

annotation class ist Kotlins direktes Pendant zu Javas public @interface — gleiche Semantik, kompakteres Schlüsselwort. @Target und @Retention kommen aus dem Kotlin-Reflection-Package und mappen auf dieselben Bytecode-At

Springs Container-Implementierung ist hierarchisch aufgebaut:

In der Praxis fragst du Spring meist gar nicht direkt — du holst dir Beans über Konstruktor-Injection, nicht über applicationContext.getBean(...). Für das Verständnis ist trotzdem nützlich:

Beispiel: Du willst einen RestClient (Klasse aus spring-web, in Spring Framework 6 eingeführt, in Boot 4 als Default-HTTP-Client etabliert), der mit deiner App-Konfiguration vorinitialisiert ist. RestClient ist nicht dei

Mehrere @Bean-Methoden vom selben Typ sind kein Problem — der Bean-Name ist standardmäßig der Methodenname und damit unterscheidbar:

Im Alltag injizierst du Beans, indem du sie als Konstruktor-Parameter deklarierst. Manchmal, vor allem in Tests oder zum Debuggen, willst du aber direkt in den Container schauen.

Lege folgende Package-Struktur an:

greeting/FormalGreetingService.kt:

greeting/CasualGreetingService.kt:

Ersetze HelloController.kt durch:

Entferne den @Qualifier-Parameter komplett:

Starte die App. Erwartet: Die App startet nicht, sondern bricht mit einer Fehlermeldung ab. Such im Stacktrace nach:

Im Controller den @Qualifier weglassen:

Lege im Package com.example.hello.greeting an: LoudGreeter.kt

Und eine @Configuration-Klasse: config/GreetingConfig.kt

Test, dass die laute Variante per Qualifier nutzbar ist:

Lege folgende Test-Klasse an: projekt/src/test/kotlin/com/example/hello/ContextInspectionTest.kt

Wenn du Lust hast, baust du dir eine semantische Qualifier-Annotation. Lege an: projekt/src/main/kotlin/com/example/hello/greeting/Casual.kt

Im Controller kannst du jetzt schreiben:

Eine Bean wird nicht einfach mit Foo() erzeugt und dann benutzt. Spring durchläuft eine definierte Sequenz von Schritten, in die du an mehreren Stellen eingreifen kannst. Das hier ist die Vollansicht. Meistens nutzt du d

Felder, die mit @Autowired, @Resource, @Value annotiert sind, werden befüllt. Setter werden aufgerufen. Bei reiner Constructor-Injection ist diese Phase ein No-op.

Genau hier greifst du im normalen Code ein:

Wird beim sauberen Shutdown des Containers aufgerufen (ctx.close(), oder bei graceful JVM-Shutdown):

Schau dir folgende @Configuration-Klasse an:

Wenn du @Bean-Methoden in einer Klasse hast, die nicht mit @Configuration annotiert ist (etwa in einer @Component-Klasse), wird kein CGLIB-Proxy erzeugt. Das ist der Lite-Mode. Folge:

Es gibt einen einzigen Fall: Wenn du eine @Component hast (klassische Service-Klasse), die zusätzlich eine @Bean-Methode anbietet, und diese Bean unabhängig von anderen @Bean-Methoden derselben Klasse ist. Beispiel:

Spring 5.2 hat eine Optimierung eingeführt: Wenn du dir sicher bist, dass die Bean-Methoden deiner Config-Klasse einander nicht aufrufen, kannst du den CGLIB-Proxy abschalten:

Du willst Properties aus application.yml in deine Beans bekommen. Es gibt zwei Hauptwege.

Statt einzelner @Value-Annotations bündelst du eine Property-Gruppe in eine eigene Klasse. In Kotlin nimmst du dafür eine data class mit Constructor-Binding:

Weg B (Scan) oder Weg C ist im modernen Spring Boot idiomatisch. Ich benutze in diesem Kurs Weg B, weil es die @EnableConfigurationProperties-Aufrufe in der Main-Klasse erspart.

Hier kommt das eigentlich interessante Pattern. Mit @Profile kannst du eine Bean nur in bestimmten Profilen aktivieren:

Statt das auf @Service-Ebene zu machen, kannst du @Profile auch auf @Bean-Methoden in einer @Configuration-Klasse setzen:

Manchmal willst du ein ganzes Bündel von Beans nur in einem Profil aktivieren:

Bei @Value und @ConfigurationProperties macht Spring das Property-Binding für dich. Du kannst auch direkt auf die Property-Quellen zugreifen, über das Environment-Bean:

Du hast @ConditionalOnClass, @ConditionalOnMissingBean und @ConditionalOnProperty in Lektion 01 als Werkzeug der Auto-Configuration kennengelernt. Du kannst sie auch selbst nutzen, vor allem in eigenen @Configuration-Kla

Lege folgende Datei an: projekt/src/main/kotlin/com/example/hello/config/AppMailProperties.kt

Damit Spring die Klasse als Bean erkennt und befüllt, fügst du @ConfigurationPropertiesScan auf der Main-Klasse hinzu:

Erweitere projekt/src/main/resources/application.yml:

Und projekt/src/main/resources/application-dev.yml:

mail/FakeMailSender.kt (Dev und alle Nicht-Prod-Profile):

mail/SmtpMailSender.kt (nur in Prod):

mail/MailService.kt:

Erweitere HelloController.kt um einen zweiten Endpoint:

Erwartet: Die App bricht beim Start ab, mit einer Fehlermeldung wie:

Lege folgenden Test an: projekt/src/test/kotlin/com/example/hello/MailSenderLifecycleTest.kt

Erweitere den StartupReporter aus Übung B2/L01 um die app.mail-Werte:

In Laravel sieht Routing- und Controller-Code etwa so aus:

Spring macht im Grunde dasselbe, packt aber alles in eine Klasse: Routing-Definition und Handler-Methoden stehen beieinander, das Mapping geschieht über Annotations direkt an der Methode. Eine separate Routes-Datei gibt

Spring kommt aus der Model-View-Controller-Welt. Bevor JSON-APIs Standard waren, hat ein Spring-Controller HTML aus Templates (JSP, Thymeleaf, Freemarker) gerendert. Die Default-Annotation dafür ist @Controller. Eine Met

Für JSON-APIs willst du aber das genaue Gegenteil: Der Rückgabewert ist der Body. Du willst keinen View-Resolver dazwischen. Genau das macht @RestController:

@RestController ist eine Composed Annotation: intern ist sie @Controller plus @ResponseBody. Das @ResponseBody sagt Spring: „Schreib den Rückgabewert direkt in den Response-Body, nutz dafür einen HttpMessageConverter." D

Die zentrale Routing-Annotation ist @RequestMapping. Sie kann an einer Klasse stehen (als Präfix) oder an einer Methode (als konkrete Route). Die Kurzformen @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchM

@RequestMapping kennt eine Reihe von Attributen, die die Kurzformen erben:

Die URL GET /users?role=admin&page=2 hat zwei Query-Parameter. So holst du sie:

Beide funktionieren analog zu @RequestParam:

Wenn du Statuscode, Headers oder Body-Typ beeinflussen willst, packst du das Ganze in ein ResponseEntity<T>:

projekt/src/main/kotlin/com/example/hello/user/User.kt

projekt/src/main/kotlin/com/example/hello/user/UserCreateRequest.kt

projekt/src/main/kotlin/com/example/hello/user/UserController.kt

projekt/src/test/http/users.http

Erweitere UserController um folgenden Endpoint:

In Laravel hast du dafür zwei Werkzeuge: FormRequest-Klassen für Validation und API-Resources für die Output-Form.

Validation-Annotations gehören vor die jeweilige Property:

Bei einem Validation-Fehler wirft Spring eine MethodArgumentNotValidException. Default-Verhalten von Spring Boot 4.0: Diese Exception wird automatisch zu einem 400 Bad Request mit einer Standardform (ProblemDetail nach R

Wenn ein DTO ein anderes DTO enthält, musst du @Valid zusätzlich am inneren Feld setzen — sonst greift die Validation nicht in die Tiefe:

Die eingebauten Annotations decken 90 % ab. Für domänenspezifische Regeln baust du dir eine eigene. Sie besteht aus zwei Teilen: der Annotation und dem Validator.

annotation class ist Kotlins direktes Pendant zu Javas public @interface — gleiche Semantik, kompakteres Schlüsselwort. @Constraint(validatedBy = [PhoneNumberValidator::class]) verknüpft Annotation und Validator-Klasse,

Wenn du einmal keine data class verwendest (Legacy-Code, JPA-Entities mit var-Properties), funktioniert Validation an klassischen Properties genauso — der @field:-Prefix bleibt:

Spring kann zusätzlich Method-Level-Validation auf Service-Methoden anwenden — dafür setzt du @Validated an die Klasse und die Annotations an die Methodenparameter:

Ein object in Kotlin ist ein Singleton-Container — hier nur als Namespace für die beiden Marker. Die interface-Deklarationen darin werden zu vollwertigen Java-Interfaces im Bytecode, exakt wie Bean Validation sie erwarte

Lies das so: name ist immer Pflicht. email ist beim Create Pflicht, beim Update optional — falls gesetzt, muss es im Mail-Format sein. Beachte das String? bei email: Beim Update darf der Client das Feld weglassen, also m

Wenn Eingabe-DTO und Domain-Objekt nicht identisch sind, brauchst du Mapping-Code. Drei Optionen stehen zur Wahl:

Einfach, explizit, ohne Tooling. Bei fünf bis zehn Feldern völlig in Ordnung. Die Mapping-Funktion als Extension-Function auf der Domain-Klasse zu schreiben (fun User.toResponse()), ist idiomatisches Kotlin — du liest sp

projekt/src/main/kotlin/com/example/hello/user/UserCreateRequest.kt — überschreiben:

projekt/src/main/kotlin/com/example/hello/user/UserUpdateRequest.kt — neu:

projekt/src/main/kotlin/com/example/hello/user/UserResponse.kt — neu:

Erweitere User.kt um phone:

projekt/src/main/kotlin/com/example/hello/user/PhoneNumber.kt:

projekt/src/main/kotlin/com/example/hello/user/PhoneNumberValidator.kt:

Der vollständige Controller danach (du darfst ihn übernehmen, lies ihn aber vorher):

Erweitere deine projekt/src/test/http/users.http:

projekt/src/main/kotlin/com/example/hello/user/ValidationGroups.kt:

UserRequest.kt (neu, parallel zu den beiden bestehenden DTOs):

Schau dir einen typischen Laravel-Controller an, wie er in vielen Projekten aussieht:

Die Lösung in Laravel wäre eine Action- oder Service-Klasse:

Spring kanonisiert dieses Muster. Es heißt dort Layered Architecture und ist nicht eine Option unter vielen, sondern die Default-Erwartung an Spring-Code. Jedes Lehrbuch, jedes Tutorial und jede Enterprise-Architektur se

In 95 % der Fälle geht es allerdings schlicht um kommunikative Klarheit: Wer @Service sieht, weiß sofort, dass hier Business-Logik wohnt.

Vorher (vereinfachte Variante aus B2/L04 und L05):

Storage und ID-Generierung leben im Controller, das Mapping steckt in einer privaten Methode. Funktioniert, vereint aber drei Verantwortlichkeiten auf einmal.

Das Repository ist der Datenzugriffs-Layer. Es kapselt, woher die Daten kommen. In B2/L07 wird daraus Spring Data JPA mit echter DB; jetzt bauen wir eine In-Memory-Variante, die dieselbe Schnittstelle hat. Damit bleibt d

3. Dependency Inversion Principle (DIP) — das „D" in SOLID. Höhere Schichten hängen nicht von konkreten Implementierungen tieferer Schichten ab.

Beide sind valide Patterns. Nullable Return ist expliziter, JPA-Exceptions sind im Aufrufcode kompakter. In dieser Lektion bleiben wir bei User?.

Die ganze Schichten-Trennung lohnt sich aus einem konkreten Grund: Tests. Der Service ist die wichtigste und gleichzeitig die am besten testbare Schicht deiner App.

Anemic Domain Model: Die Domain-Klasse (User) ist eine reine Datenstruktur ohne Verhalten. Aller Code wandert in den Service:

In B2/L07 ziehen wir das im Detail durch, hier reicht der Überblick:

Vorausblick auf die fertige Struktur:

projekt/src/main/kotlin/com/example/hello/user/UserRepository.kt:

projekt/src/main/kotlin/com/example/hello/user/InMemoryUserRepository.kt:

projekt/src/main/kotlin/com/example/hello/user/UserMapper.kt:

projekt/src/main/kotlin/com/example/hello/user/UserService.kt:

projekt/src/main/kotlin/com/example/hello/user/UserController.kt komplett ersetzen:

projekt/src/test/kotlin/com/example/hello/user/UserServiceTest.kt:

projekt/src/test/kotlin/com/example/hello/user/FakeUserRepository.kt:

Nach dem Refactor sollte dein User-Package so aussehen:

Wir bauen ein einfaches Beispiel: User mit eingebetteten Address-Objekten.

meisten Operationen unhandlich ist.

build.gradle.kts:

src/main/resources/application.yml:

src/main/resources/schema.sql:

Für alles, was über simple Property-Lookups hinausgeht, nimmst du

Data JDBC kennt mehrere Beziehungs-Typen, alle ohne @OneToMany/@ManyToOne:

Referenzen statt Verschachtelung:

hochfährt — nicht die ganze App:

Wer Audit-Spalten will, aktiviert sie mit zwei Annotations:

Bearbeite build.gradle.kts:

src/main/resources/schema.sql:

src/main/resources/application.yml:

src/main/kotlin/com/example/users/domain/User.kt:

Audit-Date aktivieren — src/main/kotlin/com/example/users/UsersApplication.kt:

src/main/kotlin/com/example/users/domain/UserRepository.kt:

src/main/kotlin/com/example/users/application/UserService.kt:

src/main/kotlin/com/example/users/web/UserController.kt:

In einem zweiten Terminal:

src/test/kotlin/com/example/users/UserRepositoryTest.kt:

Und im Test:

Du kannst pro Controller einzelne Exception-Typen abfangen:

Laravel-Brücke direkt: app/Exceptions/Handler.php mit seinem register()-Aufruf, der pro Exception-Klasse einen Callback registriert. Spring macht es per Annotation auf Methoden in einer Bean.

[RFC 7807](https://www.rfc-editor.org/rfc/rfc7807) definiert ein JSON-Format für HTTP-Fehler. Der zugehörige Content-Type ist application/problem+json. Vorgeschriebene Felder:

Wann nutzen? Immer, wenn du eine API schreibst. Drei tragende Gründe:

Bevor du Handler schreibst, brauchst du Exceptions zum Handhaben. Bau eine kleine Hierarchie pro Bounded Context:

) : RuntimeException(message, cause)

Was du brauchst: eine flache Liste der Field-Errors mit Feldname und Message.

Response sieht dann so aus:

Spring bringt eine fertige Basis-Klasse mit, die viele Standard-Web-Exceptions schon kennt: ResponseEntityExceptionHandler. Du erbst davon und überschreibst nur, was du anders willst.

Du hast in deinem Service in B2/L07 sauber mit existsByEmail vorgeprüft, aber das ist race-condition-anfällig. Zwischen deinem Check und dem Insert kann eine andere Request schon den Eintrag angelegt haben. Der DB-Constr

Praktisches Pattern im Handler:

Beide gültig:

In funktionalen Stacks (Arrow, Kotlin-Domain-Layer) siehst du oft ein Pattern, das Fehler nicht als Exceptions wirft, sondern als algebraischen Datentyp im Return-Wert zurückgibt:

Im Controller mappst du den Result-Typ explizit auf HTTP-Antworten:

Lege ein eigenes Package com.example.projekt.error an (passe an deinen Package-Namen an). Darin:

Die bestehenden Exceptions migrieren — UserNotFoundException und DuplicateEmailException erben jetzt von DomainException statt direkt von RuntimeException. Felder am Exception-Objekt ergänzen, damit der Handler sie ausle

Im selben error-Package:

requests.http ergänzen:

Im UserService.create() die existsByEmail-Vorprüfung temporär auskommentieren:

Lege einen Filter an, der pro Request eine Trace-ID generiert, in MDC packt und im Response-Header ausliefert:

Für eine kleine Vertiefung kannst du den findById-Pfad parallel als sealed-Errors-Variante anlegen, ohne den existierenden Controller zu brechen:

application.yml (modern):

Beispiel — Dev-Setup:

Statt zwei separate Files kannst du in einer Datei mit --- mehrere Dokumente bündeln und pro Block einen Profile-Filter setzen:

Die Idee: Statt einzelne Werte mit @Value("\${app.foo}") einzustreuen, mappst du einen ganzen Config-Block auf eine Kotlin-Klasse. Vorteile: Type-Safety, IDE-Completion, Validation an einer Stelle, refactorbar.

Aktivierung — eine Annotation auf einer @Configuration-Klasse (oder auf der Main-App-Klasse):

In application.yml:

Wichtig in Kotlin: Constraint-Annotationen brauchen das @field:-Target, damit sie tatsächlich am Field landen und nicht am Constructor-Parameter. Also @field:NotBlank val from: String, nicht nur @NotBlank. Spring liest d

Spring Boot bringt Logback als Default-Logger mit (zugeordnet via SLF4J). Du nutzt im Code:

Level-Hierarchie: TRACE < DEBUG < INFO < WARN < ERROR < OFF. Default-Level für root ist INFO.

src/main/resources/logback-spring.xml:

Per Default ist nur /actuator/health exposed (das reicht für Container-Healthchecks). Die anderen schaltest du explizit frei:

Security-Hinweis: Actuator-Endpoints sind ein Daten-Leak-Risiko. In Production läufst du sie auf einem separaten Management-Port und schützt sie mit Spring Security (oder per Network-Policy auf Cluster-Ebene):

Manchmal willst du eine ganze Bean nur unter bestimmten Bedingungen registrieren:

Neues application.yml (nur das, was in beiden Profilen gilt):

Neues application-dev.yml:

Neues application-prod.yml:

Neues Package com.example.projekt.config:

Auf der App-Hauptklasse @ConfigurationPropertiesScan ergänzen:

runApplication<ProjektApplication>(args)

Im UserController-Paket einen Debug-Endpoint einbauen, der die Flags lebendig zeigt:

In application.yml:

Lege zwei SearchEngine-Implementierungen an und steuere per Flag, welche aktiv ist:

Ein Controller, der einfach den SearchEngine-Bean injecten lässt und nicht weiß, welche Implementation kommt:

JUnit ist das, was PHPUnit für PHP ist: das Test-Runner-Framework. Es gibt JUnit 4 (das ältere) und JUnit 5 (auch „Jupiter" genannt, seit 2017). Im Spring-Boot-Starter ist JUnit 5 Standard. Bei alten Code-Beispielen aus

Wenn eine Klasse mehrere Szenarien testet, gruppierst du sie in @Nested-Inner-Classes. Das gibt dir hierarchische Test-Reports und einen klaren Setup-Scope pro Szenario:

Wichtig in Kotlin: inner class, nicht nur class. Sonst hat die innere Klasse keinen Zugriff auf die Felder der äußeren — und JUnit erkennt sie nicht als verschachtelte Test-Klasse.

Beide vertragen sich. Faustregel: kotlin-test für einfache Asserts, AssertJ wenn die Aussage komplexer wird.

Eine Kette: links steht was, rechts womit verglichen — wie du es im Kopf sprichst.

> Wenn du in eine bestehende Java-/Kotlin-Codebase einsteigst, die schon Mockito (org.mockito:mockito-core) + org.mockito.kotlin:mockito-kotlin nutzt, lass das so. Beide Welten funktionieren in Spring Boot 4. Für neuen K

Wenn du genau wissen willst, was der Service ans Repository übergeben hat, nimmst du einen slot:

Wenn deine Test-Klasse mehrere Mocks und das Subject-Under-Test braucht, ist die Annotation-Variante kompakter:

Wenn du eine echte Bean-Verkabelung testen willst — Service → Repository → Datenbank, alles mit Spring-DI verschaltet —, nutzt du @SpringBootTest:

Wenn du nur den Controller testen willst (Routing, Request-Mapping, Validation, JSON-Serialisierung), brauchst du keinen Persistenz-Stack:

MockMvc simuliert HTTP-Requests gegen deinen Controller, ohne echten Tomcat. Es ist schnell und sehr realistisch — der gesamte MVC-Stack läuft (Routing, Argument-Resolver, Validation, Response-Konverter).

jsonPath(...) ist eine JSONPath-Expression. $ ist die Wurzel, $.name ist das Top-Level-Property name, $.users[0].name der name des ersten Array-Elements unter users.

Repositories und Custom-Queries willst du gegen eine echte Datenbank testen, aber nicht den ganzen Webstack hochfahren. Das macht @DataJdbcTest für Spring Data JDBC (B2/L07):

Warum überhaupt zwei? Weil ein lokales mockk<T>() ein reines Kotlin-Feld in deiner Test-Klasse erzeugt, @MockkBean aber die Bean im Spring-Container ersetzt. In einem @WebMvcTest-Test braucht der Controller einen UserSer

Spring Boot bringt zusätzlich die spring-boot-testcontainers-Integration mit der @ServiceConnection-Annotation, die seit Boot 3.1 das Zusammenstecken trivial macht. Du hast das Pattern in B2/L07 schon gesehen.

RestTestClient ist nicht automatisch in @SpringBootTest injiziert; du aktivierst ihn mit @AutoConfigureRestTestClient:

> Hinweis Boot 3 → Boot 4 Migration: Wenn du Tutorials/Snippets aus 2024 findest, die WebTestClient in einem @SpringBootTest-Servlet-Setup zeigen, ist das nicht falsch, aber nicht mehr idiomatisch. Ersetze für neue Tests

Die Datei src/test/resources/sql/three-users.sql enthält Plain-SQL-Inserts. Praktisch für Setup, das du in vielen Tests wiederverwendest.

Spring-Tutorials erwähnen Coverage selten. Wenn du es willst, ist Jacoco der Standard. Plugin in build.gradle.kts:

testImplementation("io.kotest:kotest-assertions-core:5.9.1")

Es ist die Library für Auth in der Spring-Welt. Alles andere ist Selbstbau, und das macht niemand ernsthaft.

Spring Security ist in Wahrheit eine Servlet-Filter-Chain. Wenn ein HTTP-Request hereinkommt, läuft er durch eine Reihe von Filtern, bevor er deinen Controller erreicht:

Wenn du älteren Spring-Code liest, siehst du oft so etwas:

Heute schreibst du eine @Configuration-Klasse, die eine SecurityFilterChain-Bean zurückgibt. Spring Security baut daraus den FilterChainProxy. In Kotlin nutzt du dafür die Kotlin-DSL aus spring-security-config:

Wenn du eine App hast, die sowohl eine API (/api/) als auch eine Web-UI (/admin/) bedient, kannst du zwei Filter-Chains definieren — je nach URL eine andere Auth-Strategie:

fun loadUserByUsername(username: String): UserDetails

Wenn du eine eigene AppUser-Entity mit username, passwordHash und Rollen hast, schreibst du dir einen UserDetailsService, der diese aus dem AppUserRepository lädt:

OWASP empfiehlt für neue Apps seit 2023 Argon2id als ersten Algorithmus, BCrypt als akzeptable Alternative, scrypt und PBKDF2 als Drittes. Spring Security hat das alles mit dabei:

Spring Boot rendert mit einer einzigen Zeile (formLogin { }) ein komplettes Login-Formular, inklusive Default-CSS und Submit-Handling. Das ist die typische Wahl für Server-Side-Apps mit Thymeleaf (Buch 3).

loginPage = "/login" heißt: Spring Security rendert nicht mehr selbst, sondern erwartet, dass dein Controller die /login-Route bedient. Du musst dann selbst ein Thymeleaf-Template bauen:

Der idiomatische Weg in Spring Boot 4 ist spring-boot-starter-oauth2-resource-server. Das klingt nach „brauche ich nur, wenn ich OAuth2 mache", ist aber auch der Standard für „mein Service akzeptiert JWTs, egal woher die

Symmetrisch (HMAC) — gemeinsamer Secret-Key, einfach, gut für kleine Apps:

Plus eine JwtDecoder-Bean, weil Symmetric-Keys nicht aus Auto-Discovery kommen:

Asymmetrisch (RSA, JWKS) — Public-Key-Cryptography, der passende Weg, wenn ein externer Identity-Provider (Keycloak, Auth0, AWS Cognito) die Tokens ausstellt:

Für Bonus-Aufgaben/Übungs-Zwecke kannst du dir einen POST /auth/login schreiben, der einen JWT zurückgibt:

Den JwtEncoder und AuthenticationManager brauchst du als Beans:

@EnableMethodSecurity ist seit Spring Security 5.6 der Standard und seit 6 mit prePostEnabled = true als Default. In Security 7 ist @EnableGlobalMethodSecurity entfernt — ältere Codebases müssen migrieren, sonst kompilie

Faustregeln:

Spring Security muss CORS-Preflight-Requests (OPTIONS …) bewusst durchlassen. Idiomatisch:

Du kannst sie an- und ausschalten:

Wenn deine App geschützt ist, schlagen alle deine MockMvc-Tests aus B2/L10 sofort mit 401 fehl. Dafür gibt es spring-security-test mit zwei wichtigen Mechanismen.

@WithMockUser setzt vor dem Test einen authentifizierten SecurityContext mit dem gegebenen Username und Rollen. Nach dem Test räumt es auf.

Wenn dir der String-Vergleich auf "ROLEADMIN" zu lose ist, lohnt eine typsichere Rolle. In Kotlin geht das mit einer sealed-Klasse:

Der Default-JwtAuthenticationConverter extrahiert Authorities aus dem scope/scp-Claim und hängt das Prefix SCOPE davor. Wenn dein Identity-Provider Rollen unter roles oder realmaccess.roles (Keycloak) ausliefert, brauchs

Manuell testen mit curl:

JwtDecoder- und JwtEncoder-Beans im SecurityConfig definieren:

Tipp zum JSON-Parsing in MockMvc (Kotlin-DSL):

Verzeichnis-Layout, das im Rest der Lektion vorausgesetzt wird:

Kurze Wiederholung mit Schwerpunkt: Du hast einen @RestController in B2/L04 kennengelernt. Jetzt zurück zur normalen Form.

Laravel-Brücke — derselbe Controller in Laravel:

Wenn du View-Name und Model in einem Objekt zurückgeben willst:

Du gibst Daten ins Template ausschließlich über Model (oder ModelAndView, oder ein paar Edge-Cases mit @ModelAttribute-Methoden). Schau dir die wichtigsten Wege an:

Wenn du in jedem Request denselben Wert ins Model legen willst (Beispiel: aktueller Benutzer, Build-Version, Feature-Flags), schreib eine @ModelAttribute-Methode in den Controller oder in einen @ControllerAdvice:

Vor jedem Request in diesem Controller wird appVersion ins Model gelegt — im Template als ${appVersion} verfügbar. Wenn du das App-weit haben willst:

Wenn du den Index brauchst:

> val/var-Property automatisch.

templates/layouts/base.html:

templates/users/list.html — die konkrete Seite:

templates/layouts/base.html:

templates/users/list.html:

Blade-Pendant:

templates/users/row.html:

src/main/resources/messages.properties (Default-/Fallback-Sprache):

src/main/resources/messagesde.properties (Deutsch):

Spring Boot scannt messages.properties im Default-Konfigurationspfad automatisch. Du kannst alles via application.yml anpassen:

Konfiguration in einer @Configuration-Klasse:

In Produktion willst du, dass Nutzer nach einem Deployment das neue CSS sehen — nicht das alte aus ihrem Browser-Cache. Spring Boot kann das mit Content-Hash-basierten URLs lösen:

Vor Thymeleaf war im Spring-Stack JSP (JavaServer Pages) Standard für Server-Rendering — vergleichbar mit dem Vor-Blade-Pendant <?= $foo ?> in alten PHP-Templates. JSP-Templates sahen so aus:

[htmx](https://htmx.org) ist eine kleine JavaScript-Library, die HTML-Attribute hinzufügt, mit denen du AJAX, WebSockets, Server-Sent-Events und DOM-Updates ohne eigenen JavaScript-Code schreibst. Beispiel:

Im Template users/list.html:

In application.yml setz für lokale Entwicklung den Template-Cache aus:

Lege die Struktur unter src/main/resources/ an:

Lege einen neuen Controller an, parallel zum bestehenden UserController (REST). Verwende @Controller, nicht @RestController:

Baue das Layout. Es enthält Header mit Logo + Navigation + Locale-Switcher, ein <main> mit dem layout:fragment="content"-Slot, und einen Footer:

users/list.html erbt vom Layout und rendert die Tabelle. Verwende ein Fragment für die einzelne Tabellenzeile.

users/row.html:

Falls deine User-Entity kein createdAt-Feld hat, lass die Spalte weg oder ersetze sie durch ein Feld, das du tatsächlich hast.

messages.properties (Default, Englisch):

messagesde.properties (Deutsch):

Spring sucht automatisch nach templates/error/<status>.html, sobald deine App eine Exception in einen 404 verwandelt. Leg eine schlichte Seite an:

Ergänze die Keys in beiden messages.properties:

src/main/resources/static/css/app.css — minimal, aber lesbar. Du kannst gerne übertreiben, aber Mindestumfang:

Damit die UI mit Form-basierter Authentication läuft (statt Basic-Auth oder JWT für die REST-API), erweitere deine SecurityConfig aus B2/L11 um eine zweite SecurityFilterChain — eine für /api/ (stateless, kein CSRF) und

Im row.html machst du die Name-Zelle interaktiv:

Neuer Controller-Endpoint, der nur ein Fragment zurückgibt:

Und konfiguriere htmx so, dass er den Header bei jedem nicht-GET-Request automatisch anhängt:

Wie bei REST trennst du das Form-Modell von deiner Entity. Ein dediziertes Form-DTO enthält:

Der Controller stellt das leere Form bereit:

Im Template binden wir gegen das Form-Objekt:

Hier wird es interessant. Das Standard-Pattern in Spring:

Manchmal schlägt eine Business-Regel im Service fehl, nicht in der Bean-Validation — etwa „E-Mail bereits vergeben". Du fügst dann manuell einen Error in den BindingResult:

<input type="text" id="name" name="name" value="Ma" class="is-invalid">

Und im JavaScript:

Ein wiederkehrender Use-Case: „E-Mail darf nicht schon vergeben sein." Bean-Validation-Stil:

val payload: Array<KClass<out Payload>> = [],

Nach einem erfolgreichen POST willst du dem Nutzer auf der Folgeseite sagen: „User wurde gespeichert". Das ist eine Flash-Message — sie existiert genau für einen Folge-Request, dann ist sie weg.

4. Im Template ist ${flash.success} verfügbar — genau dieses eine Mal.

Hibernate-Validator hat einen Default-Key pro Constraint, den du in messages.properties überschreibst:

user.email.duplicate=This email address is already taken.

<button type="submit">Hochladen</button>

Multipart-Support ist in Spring Boot per Default an. Konfigurations-Knöpfe in application.yml:

In com.example.demo.user (parallel zu User-Aggregate und ggf. UserCreateDto/UserUpdateDto für REST):

UserService braucht zwei neue/angepasste Methoden für die UI-Use-Cases. Wenn du sie schon aus der REST-API hast — gut, dann wiederverwenden. Sonst:

Erweitere den UserViewController aus Übung B2/L12 um die fünf Form-Endpoints:

Dieselbe Datei für Create und Edit. Der Unterschied steht im formMode-Attribut.

In layouts/base.html ergänzt du im Layout direkt vor dem Content-Slot:

In users/row.html (oder direkt in list.html) eine zusätzliche Spalte mit einem Delete-Form. Kein Link für Delete — wir brauchen einen POST für CSRF-Schutz:

Auf der Detail-Seite (users/detail.html) ergänzt du in den Actions:

messages.properties — alles in Englisch:

messagesde.properties — alles in Deutsch:

In B2/L06 hast du Layered aufgesetzt:

In klassischem Layered ist UserRepository ein CrudRepository<UserEntity, Long>:

In klassischem Layered hat User Annotationen wie @Table, @Id, @MappedCollection:

→ Vertiefung im [Glossar — Adapter / Port](../GLOSSAR.md#adapter--port-hexagonal-architecture).

Wir refactoren das User-CRUD aus Buch 2. Vorher in Layered:

Nach dem hexagonalen Refactor:

Die Domain-Klasse wird zur reinen Kotlin-Klasse:

Der Outbound-Port — ein Interface, definiert vom Kern:

Der Inbound-Port — auch ein Interface:

Die Use-Case-Implementierung:

Der Outbound-Adapter:

Und das Spring-Data-ListCrudRepository ist hinter dem Adapter versteckt:

Der Inbound-Adapter (Controller):

Robert C. Martin (Uncle Bob) hat in seinem Buch „Clean Architecture" (2017) eine sehr ähnliche Idee unter anderem Namen verkauft. Er zeichnet sie als vier konzentrische Kreise:

Jeffrey Palermo prägte 2008 Onion Architecture als Reaktion auf klassisches N-Tier. Auch hier konzentrische Kreise:

Hier der ganze Service-Code von vorher (Layered) und nachher (Hexagonal) im Diff-Stil, damit du die Bewegung konkret nachvollziehen kannst.

data class CreateUserRequest(val name: String, val email: String)

Layered — der Test braucht einen MockK-Mock auf UserRepository:

Hexagonal — der Test braucht eine zweite Implementierung des Outbound-Ports:

Im projekt/-Quellbaum unter com.example.app.user strukturierst du um zu:

Eine DDD-Entity ist ein Verhaltens-Träger:

Mit Kotlins data class ist das eine Zeile:

Weitere VO-Beispiele aus dem Alltag:

Konkret: Die Aggregate-Root bekommt @Table und @Id. Kinder hängen über @MappedCollection an der Root und werden mit-geladen und mit-gespeichert. Keine @OneToMany, keine mappedBy, keine Cascade-Annotationen. Die Aggregate

Achtung — derselbe Begriff, anderer Kontext als in [B2/L07 — Spring Data JDBC](../../02-spring-boot-kotlin/07-spring-data/lesson.md): Dort hieß Repository ein konkretes CrudRepository<T, Id>-Interface. Im DDD-Sinn ist Re

Manchmal gibt es Domänen-Logik, die zu keiner Entity natürlich gehört, weil sie zwischen zwei Aggregaten lebt. Klassisches Beispiel: Geld zwischen zwei Konten transferieren.

Als Kotlin-data class:

Mit Spring kannst du sie über ApplicationEventPublisher veröffentlichen:

events.publishEvent(OrderPlaced(order.id, order.customerId, order.totalAmount(), Instant.now()))

Mit sealed interface kannst du eine algebraische Datentyp-Struktur für Domain Events bauen, an die der Compiler dich erinnert, wenn du einen Fall vergisst:

Ein Handler kann when-Exhaustiveness nutzen — der Compiler prüft, dass alle Varianten abgedeckt sind:

Genau das, was Spring üblicherweise @Service nennt.

Wenn die Erzeugung eines Aggregats komplex ist (mehrere Schritte, Cross-Validierung, Initial-Items), packst du das in eine Factory:

Das wichtigste Anti-Pattern in DDD-Welt. Eine Domain-Klasse hat nur Getter/Setter, alle Logik liegt in Services:

data class ist die Kotlin-Antwort auf Value Objects:

Wenn du eine abgeschlossene Menge von Event-Typen hast, ist sealed interface der korrekte Mechanismus:

) : PaymentEvent

Wenn dein DDD-Aggregat auch eine Spring-Data-JDBC-Entity ist:

Lege unter com.example.app.task parallel zu user einen zweiten Context an, in derselben hexagonalen Struktur:

Lege task/domain/event/TaskAssigned.kt als data class an:

task/application/port/in/AssignTaskUseCase.kt:

task/application/port/out/TaskRepository.kt:

Schau dir die Default-Struktur eines Laravel-Projekts an:

Im klassischen Spring-Tutorial-Stil sieht es identisch aus:

In Package-by-Feature sind die Top-Level-Ordner Features (oder Bounded Contexts), nicht Schichten:

In der Praxis kombinierst du Package-by-Feature mit der hexagonalen Sub-Struktur aus [Lektion 17](../01-architektur-stile/lesson.md):

In build.gradle.kts:

Optional kannst du @ApplicationModule per File-Level-Annotation an einer Kotlin-Datei anbringen, die als Package-Marker dient. Kotlin kennt das package-info.java-Konstrukt nicht direkt — der idiomatische Weg ist eine eig

Innerhalb eines Moduls ist standardmäßig alles public sichtbar von anderen Modulen — außer Klassen in einem internal-Sub-Package. Konvention:

Der wichtigste Mehrwert:

In user/api/:

Im task/-Modul ein Listener:

Eines der nützlichsten Denkmuster:

Wir nehmen das projekt/ mit user und task (aus Übungen 17 und 18) und ziehen Modulith dazu.

└── Money.kt

import org.springframework.modulith.ApplicationModule

1. Modulith-idiomatisch: nur api/ (oder spi/) ist public. Alle anderen Sub-Packages werden zu internal/. Hexagonale Schichten leben innerhalb von internal/:

Für die Lehre nehmen wir in der Übung Variante 1 — sie ist Modulith-konform und macht die Sichtbarkeitsregeln direkt sichtbar.

Die writeDocumentation() schreibt unter build/spring-modulith-docs/ Markdown-Files mit Modul-Übersicht und PlantUML-Diagrammen. Sehr nützlich für Reviews und Onboarding.

Laravels Default ist klar Package-by-Layer (app/Http/, app/Models/, app/Services/). Package-by-Feature gibt es als Konvention nicht, sondern wird in Domain-Heavy-Projekten manuell aufgebaut:

Damit wir wirklich drei Module haben, ergänze unter com.example.app.address ein drittes Feature:

Für AddressEvent bietet sich ein sealed interface an, das du in der api/-Datei direkt mit den drei Varianten kombinierst:

Pro Modul gilt jetzt die api//internal/-Konvention. Verschiebe in user/:

Dasselbe für task/:

In build.gradle.kts ergänze:

Lege für jedes der drei Module eine package-info.kt an. Die @file:-Annotation deklariert das Modul, das Package-Statement positioniert die Datei:

import org.springframework.modulith.ApplicationModule

import org.springframework.modulith.ApplicationModule

Lege src/test/kotlin/com/example/app/ApplicationModulesTest.kt an:

Lege src/test/kotlin/com/example/app/user/UserModuleIntegrationTest.kt an:

In Spring-Praxis: Wenn dein UserService 30 Methoden hat, ist er zu groß. Splittel nach Use-Case:

Typische Anti-Patterns: Eine when-Kaskade auf einem type-Feld:

OCP-konformer Refactor mit Strategy-Pattern:

class PushNotificationStrategy(...) : NotificationStrategy { / ... / }

Klassisches Verletzungs-Beispiel:

In Spring-Praxis: JPA-Inheritance-Fallen. Wenn du eine @Inheritance-Hierarchie machst:

Anti-Pattern in Spring: Ein Mega-Repository:

ISP-konform:

Klassischer Refactor, OCP-Anwendung. Mit Kotlins sealed interface und when als Expression elegant — die Permits-Liste ergibt sich aus den Klassen im selben Modul automatisch:

Wenn ein Service zu viele Verantwortungen hat:

Anti-Pattern: Ein Service ruft drei andere Services direkt auf.

notificationService.notifyAdmins(user) // direkter Call

Wenn eine Methode zu viele lokale Variablen hat und sich nur schwer zerteilen lässt, baust du eine Klasse draus:

Sieh dir das aus [Lektion 02 — Domain-Driven Design](../02-domain-driven-design/lesson.md) angesprochene Refactoring nochmal an:

In [Lektion 02 — Domain-Driven Design](../02-domain-driven-design/lesson.md) behandelt, hier nochmal als Smell: Domain-Klasse hat nur Getter/Setter, alle Verhalten in Services. Refactor mit Move-Method (4.5).

Der Service kennt hier die HTTP-Bibliothek. Wenn die Profil-API durch einen Event-Stream ersetzt wird, fällt der Service auseinander. Hexagonal-Lösung:

Lege im Wurzel-Verzeichnis des projekt/ eine Datei audit-2026-05-19.md an. Dort dokumentierst du den Befund. Vorlage:

In der audit-2026-05-19.md ergänzt du nach dem Refactor:

CompletableFuture, das er später auslesen kann).

Aktivieren musst du das pro Anwendung einmal:

Konsequenz Nummer eins, und sie ist groß: Self-Calls funktionieren nicht.

deshalb einen eigenen:

wird. Die Defaults (8 Core-Threads, unbeschränkter Queue) sind für viele Fälle vernünftig. Wenn du sie tunen willst:

CompletableFuture<T> (Java 8) ist die Antwort: ein Future, mit dem du Pipelines baust.

das beide Pfade sieht.

Für N parallele Aufrufe:

Lösung: ReentrantLock statt synchronized. Der Lock kann mit Loom-Awareness parken.

(hey -n 1000 -c 100 http://localhost:8080/slow), und schau dir die Differenz an:

Dann an irgendeiner Bean-Methode:

Erste Pflicht: gib dem Scheduler mehr Threads.

Tabelle (Flyway-Migration in B3/L08):

lockedby VARCHAR(255) NOT NULL

implementation("org.springframework.boot:spring-boot-starter-quartz")

wir die als Flyway-Migration ein.

musst du Springs AutowiringSpringBeanJobFactory setzen:

kopiert werden, aggregiert nach Region, das Ergebnis als 500-MB-CSV in einen S3-Bucket geschrieben.

sich manchmal selbst zusammenbauen — nur seit 18 Jahren ausgereift.

Ein Job ist der Container. Er hat einen Namen, eine geordnete Folge von Steps und einen Lifecycle. Du baust ihn

Stammdaten neu", „verschieb Output-File zu S3" — alles, was nicht „lies viele, verarbeite, schreib viele" ist.

Framework-Source, der bleibt Java):

den letzten Step-Context und startet ab der Stelle, an der es abgebrochen ist. Dafür ist das ganze Persistenz-Theater

Vergleichsweise viel — aber jede ist klein, Rollback-fähig, und die Lock-Dauer pro Tx ist niedrig.

Millionen Rows.

den Pages losgelassen.

FlatFileItemReader<T> liest CSV-/TSV-/Fixed-Width-Files Zeile für Zeile.

Multi-threaded Steps, Sektion 6.

JdbcBatchItemWriter<T> macht batched SQL-Inserts und -Updates.

FlatFileItemWriter<T> schreibt CSV-/TSV-/Fixed-Width-Files heraus.

Bei einem fehlerhaften Item nicht den ganzen Job killen, sondern überspringen und weitermachen.

JobParameters. Idiomatisch für Cron-getriggerte Container-Aufrufe (etwa ein Kubernetes-CronJob).

Wenn ein Operator manuell triggern können soll:

Pro Step parallel mehrere Worker-Threads:

kein Locking.

Idiomatisch annotation-basiert (@BeforeStep, @AfterChunk, ...):

2.1 Entity User hast du schon. Schreib eine zweite Klasse UserReportRow als Ziel-DTO:

3.3 Der Job verkettet beide:

Lokal hochgezogen via Docker:

application.yml:

Spring kann das beim Boot deklarieren, wenn du die Beans im Context hast:

durable=true überlebt einen RabbitMQ-Restart. Default ist false, was du fast nie willst.

mit Content-Type-Header und schickt sie an den Exchange.

spring.rabbitmq.listener.simple.acknowledge-mode: manual

Spring AMQP hat kein direktes @RetryableTopic — das ist Kafka-spezifisch. Aber via RetryTemplate baust du das

Retry-Queue.

Default. Im Lehrtext kannst du Boot-3-Tutorials zu Spring Kafka 1:1 übernehmen.

enable-auto-commit: false # wir committen selbst nach Verarbeitung

standardmäßig aktiv, das gibt dir Exactly-Once auf der Producer-Seite.

Spring Kafka hat seit 2.7 einen schicken Mechanismus:

processedat TIMESTAMP NOT NULL DEFAULT now()

assignedAt = Instant.now(),

Statt einer dedizierten Idempotency-Tabelle: nutze Versionsfelder im Ziel-Objekt.

jeder ernste DevOps-Mensch rät davon ab — Locks, Latenz, Operations-Albtraum.

Transaction wie das Business-Update.

Ein separater Publisher liest die Outbox-Tabelle und schickt an den Broker:

Kompensations-Schritten für den Rollback-Fall.

Event-Klassen — immutable, kompakt, idiomatisch.

MessageListenerContainer erzeugt — der ist im Wesentlichen eine Schleife:

Komplettes docker-compose.yml für die Übung (RabbitMQ-Pflicht, Kafka-Bonus):

@PostConstruct-Methode, die die Outbox-Tabelle anlegt:

zusätzlichen Queries:

2. Outbox-Eintrag schreiben:

6.1 Schreib einen OutboxPublisher-Component:

7.2 NotificationListener:

Flyway ist das pragmatischste Werkzeug in dieser Kategorie. Du schreibst SQL-Dateien nach einer festen Namens-Konvention, legst sie in einen Classpath-Ordner, und Flyway erledigt den Rest.

Im application.yml minimal:

V001createuserstable.sql:

Beim ersten migrate legt Flyway eine Tabelle an:

Flyway-Migrations sind klassisch in Java geschrieben (das Framework-Source ist Java) — der Aufruf-Konvention nach muss die Klasse im Package db.migration liegen und BaseJavaMigration erweitern. In Kotlin sieht das so aus

Vor einem Production-Deploy willst du wissen, ob die Migration durchläuft, ohne die App zu starten. Dafür gibt es die Flyway-CLI als Docker-Image:

implementation("org.liquibase:liquibase-core")

db/changelog/001-create-users.yaml:

Die XML-Variante ist die ursprüngliche und liest sich für viele Java-Entwickler vertrauter:

In einem Modulith hat jedes Modul seine eigene Verantwortung. Wenn jedes Modul eigene Tabellen besitzt (was die Modulith-Idee verlangt), gehört auch jeder Schema-Teil ins jeweilige Modul:

Laravel-Migrations sind PHP-Klassen mit up() und down(), gerne mit dem Schema-Builder geschrieben:

Weg B — Hibernate generieren lassen: vorübergehend in application.yml:

Das Resultat sieht je nach Entities ungefähr so aus:

In application.yml:

In der Task-Entity (JPA-Variante in Kotlin — kotlin("plugin.jpa") macht den No-Arg-Konstruktor):

implementation("com.github.ben-manes.caffeine:caffeine")

runApplication<HelloApplication>(args)

Mehr braucht es nicht. Ohne Caffeine im Classpath nimmt Spring einen ConcurrentMapCacheManager (eine simple ConcurrentHashMap) — funktioniert für Lerndemos, hat aber keine Eviction, kein TTL, keine Limits. Sobald es erns

Vorsicht jedoch: Cache-Konsistenz mit @CachePut ist anfällig, sobald andere Wege existieren, die dieselben Daten ändern (DB-Trigger, andere App-Instanzen ohne synchronisiertes Caching, Migrations). Idiomatischer ist oft,

Wenn eine Operation mehrere Caches gleichzeitig anfasst (z. B. einen User updaten, der in users und in tasksByUser referenziert wird):

fun update(id: Long, req: UserUpdateRequest): User { / ... / }

Ohne key-Angabe generiert Spring einen Default über SimpleKeyGenerator — das Tuple der Parameter, bzw. SimpleKey.EMPTY bei keinem Parameter. Funktioniert, aber bei refactor-anfälligen Signaturen ist eine explizite Angabe

Du kennst das schon von @Transactional (B2/L07) und @Async (B3/L05): Spring implementiert die Annotation per AOP-Proxy. Der Container gibt dir nicht deine Klasse, sondern einen Proxy, der deine Klasse umschließt.

2. Self-Reference-Pattern. Den eigenen Service per Constructor injizieren (mit @Lazy, damit Spring den zirkulären Verweis sonst nicht auflösen muss):

Konfiguration über spring.cache.caffeine.spec:

Wenn du pro Cache unterschiedliche Specs brauchst, baust du den CacheManager manuell:

// spring-boot-starter-cache ist eh schon drin

Redis via Docker:

Neu in Spring Boot 4 — MicrometerTracing in der Redis-Auto-Config: Sobald micrometer-tracing und ein Tracer (Brave oder OpenTelemetry) im Classpath sind, instrumentiert die Redis-Auto-Configuration die Lettuce- bzw. Jedi

Wenn eine Mutation einen Domain-Event auslöst (B3/L02), kannst du Cache-Invalidation als Event-Listener bauen:

Über Transaktionen hinweg, in derselben JVM. Du musst ihn explizit aktivieren mit z. B. EHCache:

Auf der Hauptklasse:

In application.yml:

Im UserService:

Stell sicher, dass application.yml JPA-SQL-Logging hat (aus B2/L07):

Wenn der zweite Call ein zweites SQL feuert, ist etwas nicht in Ordnung. Erste Verdachtsmomente:

Ohne Cache-Evict würde der Cache nach einem Update veraltete Daten ausliefern. Zum Beweis kommentierst du das @CacheEvict temporär aus, startest die App neu und gehst so vor:

Der Fix ist Self-Injection:

compose.yaml im Projektroot (oder ergänze deine bestehende):

In application.yml:

Die Java-Default-Serialisierung in Redis funktioniert zwar, ist aber unleserlich und versionierungs-fragil. Stell auf JSON um:

Im Log von Instance B siehst du keinen findById: DB-Hit und kein SQL. Der Cache-Eintrag, den Instance A geschrieben hat, kommt bei Instance B ohne DB-Zugriff an. Genau das ist der Sinn von Redis.

In einer rein Caffeine-basierten Multi-Instance-App hättest du dagegen Folgendes gesehen: Instance A evictet seinen lokalen Cache, Instance Bs lokaler Cache hält den Eintrag aber noch — name bleibt veraltet. Genau dafür

OAuth definiert vier Rollen, und es lohnt sich, die im Kopf sauber zu halten:

Das ist der Flow für interaktive Apps — Web mit Server-Backend, SPAs (React, Vue, Angular), Mobile-Apps. Seit OAuth 2.1 immer mit PKCE (Proof Key for Code Exchange), auch wenn du Server-Side bist.

Kein User im Spiel. Eine Backend-App authentifiziert sich gegen einen Auth-Server und holt sich ein Token für ihre eigene Identität — typisch für Service-to-Service-Kommunikation:

Für Geräte ohne richtige Tastatur oder Browser (Smart-TV, Konsolen-CLI, Drucker). Das Prinzip: Das Gerät zeigt einen Code an, der User loggt sich auf einem zweiten Gerät (Smartphone) ein und gibt dort den Code ein.

Ein typisches Access-Token von Keycloak sieht decodiert so aus:

Im Projektordner eine docker-compose.yml:

Lege im projekt/-Verzeichnis einen Ordner infra/keycloak/ an mit einer docker-compose.yml:

Im Terminal:

Schritt 7.2 — Authorization-URL bauen und im Browser öffnen

Schritt 7.3 — Code gegen Token tauschen

Response (gekürzt):

Schritt 7.6 — Refresh-Token verwenden

In Keycloak hast du oben bei „Service accounts roles" einen Service-Account aktiviert. Im Clients → task-app → Service accounts roles Tab kannst du diesem die Rolle USER zuweisen (für den Test).

Im Keycloak-Admin: Clients → task-app → Advanced → OAuth 2.0 Device Authorization Grant Enabled: on speichern.

Du bekommst zurück:

Im Terminal pollen:

Mehr ist Code-seitig zunächst nicht nötig. In application.yml:

Spring Boot fragt beim Startup automatisch http://localhost:8081/realms/springkurs/.well-known/openid-configuration ab, holt sich von dort die jwksuri und cached die Public Keys. Damit ist der Resource Server konfigurier

In deinem Controller:

Keycloak schickt Rollen aber nicht im scope, sondern im realmaccess.roles-Sub-Claim. Wenn du @PreAuthorize("hasRole('ADMIN')") nutzen willst, musst du Spring beibringen, von dort zu lesen:

Keycloak unterscheidet Realm Roles (realmaccess.roles) und Client Roles (resourceaccess.<client-id>.roles). Wenn du Rollen lieber pro Client (= App) modellieren willst:

Lösung: ein zusätzlicher OAuth2TokenValidator:

Eine Minimal-Konfiguration:

implementation("org.springframework.boot:spring-boot-starter-oauth2-client")

{baseUrl} und {registrationId} sind Spring-Platzhalter. Die effektive Redirect-URL wird http://localhost:8080/login/oauth2/code/keycloak — also genau das, was du in Keycloak unter „Valid redirect URIs" eingetragen hast.

Was hier passiert:

In manchen Architekturen ist deine Spring-App beides — sie rendert HTML und stellt gleichzeitig eine JSON-API bereit. Dann brauchst du zwei SecurityFilterChain-Beans mit @Order:

Wenn deine Server-Side-App im Namen des Users fremde APIs aufrufen will (z. B. Google Drive), brauchst du den Access-Token. Spring stellt ihn via OAuth2AuthorizedClient bereit:

Spring-Security-Test stellt einen JWT-Postprocessor zur Verfügung — damit muss kein echter Keycloak im Test laufen:

Wenn du das Ende-zu-Ende verifizieren willst, geht das mit Testcontainers:

Den vorhandenen starter-security und spring-security-test lässt du drin. Wer in B2/L11 spring-boot-starter-oauth2-resource-server schon fürs Bonus-JWT eingebaut hatte: Property app.jwt.secret und die selbst gebaute JwtEn

In UserControllerWebMvcTest.kt:

Lege eine Test-Klasse KeycloakLiveTest.kt an, per Default deaktiviert (mit @Disabled oder @EnabledIfEnvironmentVariable):

Lass den Test in CI nur laufen, wenn die ENV-Variable KEYCLOAKLIVETEST=true gesetzt ist. Lokal kannst du ihn manuell starten, sobald dein Docker-Compose-Keycloak hochläuft.

application.yml ergänzen:

In SecurityConfig.kt:

Eine Mini-Controller-Methode:

In B3/L11 hast du Keycloak-Roles in Spring-Authorities gemappt. Damit hast du RBAC:

Für eine Role-Hierarchy (ADMIN > EDITOR > USER, also Admin erbt alle User-Rechte) legst du eine Bean an:

In Kotlin lässt sich eine Policy direkt als data class modellieren — gut zu lesen, gut zu testen:

Lege eine Bean an, die einen logischen Namen bekommt:

In der annotierten Methode nutzt du sie via SpEL und Bean-Namen mit @-Prefix:

Alle drei laufen als eigener Service (Docker), stellen eine gRPC- und HTTP-API bereit, deine Spring-App schickt check-Calls dorthin.

Authorization-Model definieren (DSL):

Spring-Client-Library: [fga-sdk](https://github.com/openfga/java-sdk). Beispiel-Call in Kotlin:

Option A — Tenant-Predicate in jedem Repository-Query:

Option B — TenantContext (ThreadLocal) + AOP-Aspect, der die Tenant-ID einmal pro Request setzt und in jede Repository-Methode automatisch reinreicht:

Mit einem OncePerRequestFilter, der TenantContext aus dem JWT-Claim füttert:

Wer bestehende JPA-Codebases pflegt oder die Hibernate-Filter-Ergonomie braucht, findet die @Filter-Variante in B3/L24 (JPA-Legacy). Wir bleiben in der Lektion bei Data JDBC.

Service-Schicht ruft TenantContext.get() einmal pro Methode auf und reicht den Wert durch:

Wenn deine ABAC-Logik canRead(taskId) heißt und dazu ein DB-Query macht, hast du bei einem Listing mit 100 Tasks 100 Permission-Checks — 100 zusätzliche Queries. Das ist das N+1-Problem in der Permission-Schicht.

Die Annotations aus org.springframework.data.annotation funktionieren in Spring Data JDBC genauso wie in JPA. Die Task-Entity aus 6.5 hat sie schon. Was du brauchst:

Wenn deine Task-Entity noch nicht existiert, lege sie an. Erweiterte Version als Kotlin data class:

Flyway-Migration V…addownertenantaudittotasks.sql:

(Wenn du H2 im Dev-Profil hast: die Spaltentypen passen, BIGINT ist identisch.)

fun clear() = current.remove()

Wichtig: Der Filter muss nach dem BearerTokenAuthenticationFilter laufen, weil er den SecurityContext schon braucht. Ordered.HIGHESTPRECEDENCE + 10 ist der pragmatische Wert — falls die Reihenfolge nicht greift, FilterCh

Wichtig: @EnableJdbcAuditing (nicht @EnableJpaAuditing) — wir sind in Data JDBC.

Die geerbten findAll(), findById(), deleteById() aus ListCrudRepository benutzt du in produktiven Service-Methoden nicht — sie kennen kein Tenant-Predicate. Halte dich an ForTenant-Varianten.

Beachte: Der Check nutzt findByIdForTenant — wenn ein User aus Tenant 1 nach Task 42 aus Tenant 2 fragt, gibt das Repository schon null zurück. Der Security-Check fällt damit automatisch auf false. Defense in Depth: zwei

return ResponseEntity.noContent().build()

Beachte den data class-Stil: current.copy(...) für Updates statt Setter. Immutable-by-default ist in Data JDBC der idiomatische Weg.

Kein spring-boot-starter-aop — wir brauchen ihn nicht, weil wir den Hibernate-Filter-Aspect aus der JPA-Welt nicht haben.

assertThat(checker.canEdit(1L, userAuth("u1", "USER"))).isFalse

TenantIsolationTest.kt mit Testcontainers Postgres (so wie in B2/L07):

.andExpect(jsonPath("$[0].title").value("A"))

Ein ConnectionCustomizer, der pro Connection SET app.tenantid setzt:

projekt/infra/openfga/docker-compose.yml:

docker compose up -d. Im Browser http://localhost:3000 für den Playground.

FgaConfig.kt:

FgaSecurityChecker:

Das ist das, was die meisten meinen, wenn sie „REST" sagen:

Hypermedia as the Engine of Application State. Roy Fielding (der die Diss zu REST geschrieben hat, 2000) versteht unter „echtem REST" eigentlich nur Level 3. Idee: Die Response enthält Links zu allen sinnvollen Folge-Akt

Spring bietet dafür Spring HATEOAS (eigene Library, spring-boot-starter-hateoas):

Stolperfalle: Die Default-Page-Size ist 20. Schickt jemand ?size=1000000, baut Spring das ungebremst aus. Setze einen oberen Deckel:

Implementierungsskizze:

Im Controller:

OpenAPI (früher Swagger) ist eine YAML- oder JSON-Spezifikation, die eine REST-API komplett maschinenlesbar beschreibt: Endpoints, Parameter, Request- und Response-Schemas, Status-Codes, Auth-Schemes, Beispiele. Aktuelle

Du musst nichts annotieren, um etwas zu sehen — SpringDoc leitet das aus den vorhandenen Annotationen ab. Für Production-taugliche Doku ergänzt du an den passenden Stellen.

@Schema direkt am Property einer data class funktioniert genauso (Spring Boot 3+/4 + Jackson 2.16+):

Für Konsumenten deiner API ist das ein erhebliches Geschenk. Für dich selbst ist es ein Smoke-Test während der Entwicklung.

Globale API-Info gibst du in einer @Configuration-Klasse mit einer OpenAPI-Bean an:

SpringDoc unterstützt Groups:

Du aktivierst es über einen WebMvcConfigurer-Callback und sagst, wo die Version im Request steht:

Spring Boot 4 hat parallel einige spring.mvc.apiversion.-Properties (Stand 4.0.6 noch in Bewegung — die WebMvcConfigurer-Variante ist der stabile Weg). Wenn du sie nutzt, ist es analog dazu:

Sobald der Versioning-Resolver konfiguriert ist, taggst du deine Handler:

SpringDoc 2.8 versteht das native Versioning. Wenn du Groups nach Version splitten willst:

In Spring umgesetzt:

Neue Datei projekt/src/main/kotlin/com/example/projekt/config/OpenApiConfig.kt:

Optional in application.yml:

Im UserController (Pfad bleibt wie er ist, also /api/v1/users oder was du hast — wir versionieren gleich richtig):

// delete, update analog

In UserCreateRequest (data class):

Lege neuen Controller an: UserControllerV1Deprecated.kt:

Neue Test-Klasse projekt/src/test/kotlin/com/example/projekt/openapi/OpenApiSpecTest.kt:

Wenn dein Projekt schon Admin-Endpoints hat (oder du legst beispielhaft welche an), trennst du sie per GroupedOpenApi:

Wenn du das Stripe-Pattern aus der Lektion umsetzen willst (z. B. für POST /api/v1/tasks), ergänze:

In jeder Klasse, in der du loggen willst, holst du dir einen Logger:

Auf Log4j2 umschalten in Spring Boot (build.gradle.kts):

Wer das Idiom mit javaClass oder companion object immer noch klobig findet, kann die Bibliothek io.github.oshai:kotlin-logging dazunehmen. Sie bietet einen SLF4J-Wrapper mit Lambda-API:

Die Logger-Hierarchie folgt der Package-Hierarchie: Ein Logger com.example.projekt.user.UserService erbt das Level seines Parent-Loggers com.example.projekt.user, der erbt von com.example.projekt, der von com.example, de

Disziplin in Production:

Reicht für Standardfälle:

dann src/main/resources/logback-spring.xml:

MDC = Mapped Diagnostic Context. Eine Map<String, String> pro Thread (ThreadLocal-basiert), deren Werte automatisch in Log-Patterns interpoliert werden — %X{userId} im Pattern liest aus dem MDC.

Spring-Idiom: ein OncePerRequestFilter:

Wenn der User authentifiziert ist (B2/L11), kommt seine Identität im SecurityContextHolder. Im selben Filter (oder einem nachgelagerten):

Lösung: ein TaskDecorator, der den MDC vom aufrufenden Thread auf den Worker kopiert:

In der TaskExecutor-Konfiguration:

Seit Spring Boot 3.4 gibt es logging.structured.format. Boot 4 hat das Feature weiter ausgebaut. Vor allem das ECS-Mapping (Stack-Trace-Felder, Exception-Klassennamen) ist konsistenter, und du kannst per logging.structur

Output mit ecs:

Du willst Plaintext in Dev und JSON in Prod. Pattern:

implementation("net.logstash.logback:logstash-logback-encoder:7.4")

Praktischer Helper für maskiertes Logging:

Jeden eingehenden Request mit Methode, Pfad, Status, Dauer loggen. Pflicht für jede API.

Geschäftsrelevante Events (User angelegt, Berechtigung geändert, Order angenommen) gehören in ein separates Log und nicht in den Stream mit den Anwendungs-Logs. Pattern:

Im logback-spring.xml schickst du den Logger AUDIT an einen separaten Appender (eigene Datei, eigener Index im Aggregator):

Aus B2/L08 bekannt, hier in Reinform:

In Spring umgesetzt: einen ClientHttpRequestInterceptor für deinen RestClient/WebClient, der MDC-Werte als Header propagiert.

Neue Datei projekt/src/main/kotlin/com/example/projekt/logging/CorrelationIdFilter.kt:

In application.yml (oder im Default-Block, falls du Profile separiert hast):

Neue Datei projekt/src/main/kotlin/com/example/projekt/logging/UserMdcFilter.kt:

Erstelle eine Async-Konfiguration, falls noch nicht vorhanden. Datei projekt/src/main/kotlin/com/example/projekt/config/AsyncConfig.kt:

Jetzt ein Service mit einer @Async-Methode, um zu zeigen, dass die ID korrekt rüberkommt. Beispiel in UserService oder neu — NotificationService.kt:

Und im Controller einen Endpoint, der das aufruft:

Erweitere application.yml:

Wenn du noch Zeit hast: einen RequestLoggingFilter bauen, der pro Request eine Zeile mit Methode, Pfad, Status und Duration loggt:

Im UserService einen separaten Logger anlegen:

Modul-Definition via Package-Konvention: Jedes Top-Level-Package unterhalb der @SpringBootApplication-Klasse ist ein Modul. Da Kotlin kein package-info.java kennt, nutzt du eine package-info.kt mit einem @file:JvmName("p

Modul-Annotation in Kotlin (File-Level-Annotation in einer leeren ModuleMetadata.kt):

Schreib in projekt/architecture-decision.md eine vollständige Decision-Doc im folgenden Format:

Selbst wenn deine Entscheidung „Microservices" lautet — skizziere als Vorstufe den Modulith-Schnitt: Wenn das Projekt heute als Modulith strukturiert würde, wie sähe die Package-Struktur aus? Schreib in projekt/architect

Der Klassiker seit Spring 3.0 (2009). Synchron, blocking, basiert auf HttpURLConnection oder Apache HttpClient.

Fluent-API über RestTemplate-Infrastruktur, aber moderner und ergonomischer. Synchron.

Mein Default für synchrone Calls in neuen Spring-Boot-4-Projekten — sofern du keine @HttpExchange-Interfaces nutzt (siehe §3.5).

@HttpExchange als Annotation existiert seit Spring Framework 6.0. Du beschreibst dein HTTP-API als Kotlin-Interface, und Spring generiert eine Proxy-Implementierung zur Laufzeit. Bisher (in Boot 3.x) musstest du den Prox

Interface-Definition (genauso wie vorher, in Kotlin als interface):

Registrierung über @ImportHttpServices auf der Application-Klasse (oder einer @Configuration):

Konfiguration über application.yml — das ist der eigentliche Wert der Auto-Config:

Verwendung wie eine normale Spring-Bean: Der Proxy ist als Bean registriert, du injectest ihn über den Konstruktor.

Anpassung des Clients pro Gruppe geht über eine HttpServiceGroupConfigurer-Bean (selten nötig, wenn du keine spezielle Logik brauchst):

Aktivierung:

Interface-Definition:

Verwendung wie eine normale Bean:

Wenn du auf Kubernetes deployst, brauchst du wahrscheinlich kein eigenes Discovery-Tool. Jeder K8s-Service hat einen eigenen DNS-Namen (user-service.default.svc.cluster.local), und der integrierte Service-Proxy (kube-pro

Discovery, Health-Checks und K/V-Store. Funktional vergleichbar mit Eureka, aber breiter aufgestellt — auch außerhalb der Java-Welt verbreitet, Go-, Python- und Node-Services können sich registrieren. Spring-Cloud-Integr

Der Klassiker. Ein Discovery-Server, bei dem sich Services registrieren („ich bin user-service, laufe auf 10.0.0.5:8080, hier mein Health-Endpoint"). Andere Services fragen den Discovery-Server „Wo ist user-service?" und

fetch-registry: false

Service-Seite:

Ein dedizierter Service, der die application.yml-Dateien aus einem Git-Repo ausliefert. Services fragen beim Start nach ihrer Config.

runApplication<ConfigServerApp>(args)

Im Config-Repo legst du Dateien an wie user-service.yml, user-service-prod.yml, application.yml (global). Der Client:

Auf K8s ist die einfachere Antwort: Config in einer ConfigMap, Secrets in einem Secret, beides in den Pod gemountet als Env-Variablen oder als Files.

Konfiguration (application.yml):

Verwendung als Annotation:

Konfiguration:

randomized-wait-factor: 0.5

Begrenzt die Anzahl gleichzeitiger Calls über eine Semaphore. Keine separaten Threads.

Eigener Thread-Pool pro Dependency. Schwerer, aber bietet stärkere Isolation.

Begrenzt Calls pro Zeitperiode. Schützt entweder deinen eigenen Service oder dient als Höflichkeits-Limit gegenüber einem externen Service mit Quota.

Erzwingt einen harten Timeout für asynchrone Calls (CompletableFuture).

Konsequenz: Wenn du @CircuitBreaker auf eine private Methode setzt oder eine Methode innerhalb derselben Klasse aufrufst, greift die Annotation nicht. Self-Invocation umgeht den Proxy. In Kotlin kommt eine zweite Stolper

private fun getUserInternal(id: Long): UserDto = client.get()...

Ein typischer Spring-Boot-4-Microservice in 2026 hat folgende Inter-Service-Konfiguration, basierend auf @HttpExchange-Auto-Config plus Resilience4j:

HTTP-Client als @HttpExchange-Interface — ohne manuellen Bean-Setup:

Application-Klasse mit @ImportHttpServices:

Wrapper-Service mit Resilience-Annotations. @HttpExchange-Interfaces lassen sich nicht direkt annotieren (Proxy auf Proxy), daher schiebst du einen Service davor.

Erstelle im projekt/-Verzeichnis (oder in einem neuen Unterordner projekt-microservices/, wenn du das bestehende Projekt nicht überschreiben willst) ein Multi-Project-Gradle-Layout:

Root build.gradle.kts definiert gemeinsame Plugin-Versionen und Repositories:

Die Daten kannst du hardcoded in einer Map halten, ein DB-Setup ist nicht nötig. Hier geht es nicht um User-CRUD, sondern um Inter-Service-Communication.

user-app läuft auf Port 8081:

data class TaskDto(val id: Long, val title: String, val assignee: UserDto)

TaskService ruft UserClient auf, um den User-Anteil zu holen:

UserClient mit RestClient:

HttpClientConfig für die RestClient-Bean:

task-app/src/main/resources/application.yml:

enabled: true

> Migration aus Boot 3.x: Das alte Artifact spring-cloud-starter-gateway mappt in Spring Cloud 2025.x weiterhin auf den WebFlux-Server (rückwärtskompatibel). Bei einem Greenfield-Setup in Boot 4 bevorzuge die expliziten

Filter sind der eigentliche Hebel.

Spring Cloud Gateway hat etwa 30 eingebaute Filter (siehe Doku) — AddRequestHeader, RemoveRequestHeader, RewritePath, Retry, CircuitBreaker, RequestRateLimiter, SetStatus, StripPrefix, …

Statt YAML kannst du Routen auch programmatisch definieren. Spring Cloud Gateway bringt seit der 4.x-Linie eine Kotlin-DSL (gateway { … } Receiver-Block) mit, die deutlich knapper ist als die Java-Variante:

Beispiel: User-Registrierung

Choreography baust du typischerweise auf Spring Kafka oder Spring AMQP (RabbitMQ) in Kombination mit dem Outbox-Pattern auf (B3/L07 hat das eingeführt). Skizze:

Im notification-service:

In einer Saga können Events mehrfach ankommen (At-Least-Once-Delivery). Dein Consumer muss idempotent sein:

Erweitere das projekt-microservices/-Setup aus B3/U16 um ein drittes Sub-Projekt:

api-gateway/build.gradle.kts zieht die Spring-Cloud-BOM (Version 2025.0.x, kompatibel zu Boot 4) und spring-cloud-starter-gateway-server-webflux rein:

ApiGatewayApplication.kt:

api-gateway/src/main/resources/application.yml:

Starte alle drei Apps (user-app:8081, task-app:8082, api-gateway:8080).

Schreib einen Global-Filter, der einen Header Authorization: Bearer <token> erwartet, das Token (vereinfacht) gegen einen statischen Wert prüft und im Erfolgsfall einen vertrauenswürdigen Header X-User-Id setzt, den Down

notification-app/build.gradle.kts:

notification-app/src/main/resources/application.yml:

data class WelcomeEmailFailedEvent(val userId: Long, val messageId: String)

RabbitMQ-Config in user-app:

Kompensations-Listener:

notification-app:

): Binding = BindingBuilder.bind(queue).to(exchange).with("user.registered")

Bevor wir an Tuning denken: was läuft da eigentlich, wenn du java -jar app.jar startest?

sterben jung" (die Weak Generational Hypothesis).

hast du ein Problem.

Recording starten mit jcmd:

Die Hauptanwendung sind Flame Graphs.

Heap-Objekte zum aktuellen Zeitpunkt.

ja, da ist ein Cache, der nie evicted wird. Bug gefunden.

Beispiel-Setup (Gradle Kotlin DSL, mit dem me.champeau.jmh-Plugin):

Beispiel-Benchmark — zwei String-Hash-Implementationen vergleichen:

Das ist mit Abstand das häufigste Performance-Problem in JPA-Apps. Wenn dein p95 plötzlich rauscht, prüf das

Bau in projekt/ einen Endpoint, der bewusst eine messbare Last erzeugt — sonst hast du im JFR-Recording nichts

Mit k6: lege loadtest.js neben dein Projekt:

Während der Lasttest läuft, in einem zweiten Terminal:

Refactor den Endpoint:

benchmarks/build.gradle.kts):

Schreib HashBenchmark.kt:

Probiere verschiedene Heap-Größen:

so etwas wie:

implementation("org.springframework.session:spring-session-data-redis")

wird seit Jahren von Brett Wooldridge gepflegt — keine Boot-4-Migrations-Sorgen.

entlastest du den Primary und kannst nahezu linear skalieren.

In Spring konfigurierst du das mit zwei DataSources:

Im Service-Code:

Cluster-Modus). Pflicht für jedes horizontale Deployment.

Der Horizontal Pod Autoscaler (HPA) ist Kubernetes eingebauter Mechanismus. Eine HPA-Definition:

Queue-Tiefe (für Worker-Apps).

Beispiel k6:

In application.yml:

Bau einen kleinen Test-Endpoint, der eine Session-Variable setzt und liest:

Lege docker-compose.yml neben dein Projekt:

Und nginx.conf mit Round-Robin-LB:

In einem zweiten Terminal:

Bau einen einfachen DB-lastigen Endpoint:

Setze HikariCP klein an:

Stoppe und starte Compose neu. Fahr einen Lasttest:

Erweitere docker-compose.yml um eine zweite Postgres-Instanz als „Replica":

Im Code: zwei DataSources + Routing.

application.yml:

Bau einen Endpoint, der das demonstriert:

Per Default ist nur /actuator/health exponiert — sicheres Default. Alles andere musst du bewusst freischalten:

Health-Checks sollen ehrlich antworten — nicht nur „der HTTP-Server steht", sondern „die Datenbank ist tatsächlich erreichbar und ich kann eine Query absetzen". Spring bringt für die Standard-Stacks (DataSource, Redis, R

Auch für die DB direkt — ein typisches Beispiel, das die Lektion gleich zweimal aufgreift:

Spring Boot 4 unterscheidet das per Default via Groups:

Spring registriert dir eine MeterRegistry-Bean (in Boot 4 + Actuator: PrometheusMeterRegistry, wenn der Prometheus-Starter dabei ist; bei aktivem spring-boot-starter-opentelemetry zusätzlich eine OtlpMeterRegistry, falls

Für simple Timing-Use-Cases gibt es Annotations, die einen Timer automatisch um die Methode legen:

Gauges sind tückisch, weil sie eine Referenz auf ein Objekt halten.

Beispiel-Output:

prometheus.yml:

Eigene Dashboards baust du in der Grafana-UI per Drag-and-Drop. Queries gegen Prometheus laufen in PromQL:

Alerts werden in Prometheus als Rules definiert:

Spring Boot hat Micrometer Tracing als Facade vor beiden — du programmierst gegen die Micrometer-Tracing-API und wählst zur Build-Zeit, welche Implementation reinkommt. In Spring Boot 4 ist das idiomatisch in einem einzi

Die wichtigen Properties:

Auto-Instrumentation deckt 90 % ab. Manchmal willst du eine eigene Operation explizit als Span sichtbar machen:

In application.yml:

In strukturiertem JSON-Log:

In jedem Spring-Modul (gateway/, user-app/, task-app/) im build.gradle.kts:

In allen drei Services in application.yml:

In user-app schreibe einen Indicator für die DB-Verbindung (Spring bringt einen automatischen mit — verifiziere, dass er da ist) und einen für RabbitMQ (falls du in B3/L07 RabbitMQ eingeführt hast). Falls noch keine MQ-A

a) Counter — users.created:

b) Timer — task.assignment.duration über @Timed:

c) Gauge — tasks.active.count:

Im Projekt-Root compose.observability.yaml:

observability/prometheus.yml:

observability/tempo.yaml:

observability/grafana/datasources/datasources.yml:

In Prometheus eine Alert-Rule definieren (observability/alert.rules.yml, dann in prometheus.yml referenzieren):

Punkte 1 und 2 lösen wir mit Multi-Stage und Layered Jars. Punkt 3 ist akademisch — für Spring-Boot-Apps in K8s reicht der Default.

Das erzeugt ein Verzeichnis pro Layer. Das nutzt du im Dockerfile:

Output (gekürzt):

Konfiguration in build.gradle.kts:

Wenn du eigene Libraries oder dynamisches Verhalten hast, das AOT nicht automatisch findet, musst du Reflection-Hints liefern:

Seit Spring Boot 3.2 (und in Boot 4 stabilisiert) gibt es eine zweite Antwort auf das Cold-Start-Problem: CRaC (Coordinated Restore at Checkpoint). Die Idee dahinter: du startest deine App einmal ganz normal, lässt sie w

Spring Boot 4 bietet /actuator/health/liveness und /actuator/health/readiness als getrennte Endpoints (seit Boot 2.3 etabliert). K8s-Manifest:

K8s scheduled Pods basierend auf Requests und enforcet hartes Cap mit Limits:

terminationGracePeriodSeconds: 60 # gib der App 60s

Kustomize — Patches-on-Bases statt Templates. Du hast ein base/-Verzeichnis mit Default-Manifests und ein overlays/prod/-Verzeichnis mit Patches:

GitHub Actions als CI:

Paketo Buildpacks lösen Problem 2 mit einem Java Memory Calculator. Beim Pod-Start läuft ein Init-Script, das aus dem Container-Memory-Limit, der Klassen-Anzahl, der Thread-Stack-Size und der GC-Wahl die optimalen JVM-Fl

Wir nehmen user-app/ als Referenz. Lege im Modul ein Dockerfile an:

Lege außerdem ein .dockerignore an:

docker run --rm -p 8081:8080 projekt/user-app:dockerfile

In user-app/build.gradle.kts:

In user-app/build.gradle.kts das GraalVM-Buildtools-Plugin aktivieren (kommt aus dem Spring-Initializr-Template, ggf. manuell ergänzen):

In user-app/src/main/resources/application.yml:

projekt/k8s/configmap.yaml:

projekt/k8s/secret.yaml:

projekt/k8s/deployment.yaml:

projekt/k8s/service.yaml:

projekt/k8s/ingress.yaml:

projekt/k8s/hpa.yaml:

Wenn du Zeit hast:

Stell es dir als Pipeline vor — die Tools picken in unterschiedlichen Phasen deiner Code-Reise:

build.gradle.kts:

Beispiele, die SpotBugs findet:

Compiler-Plugin-Setup für Gradle:

Was ErrorProne findet (Auswahl der ~500 Bug-Patterns):

Setup als ErrorProne-Plugin in Gradle:

build.gradle.kts:

Beispiel-Regeln aus detekt.yml:

build.gradle.kts:

pmd-ruleset.xml:

Spotless ist die jüngere, idiomatischere Lösung: es formatiert automatisch während des Build (./gradlew spotlessApply) und checkt im CI (./gradlew spotlessCheck). Es kann Google-Java-Format, Palantir-Java-Format, Eclipse

Setup über das sonarqube-Gradle-Plugin:

Eine erste Test-Klasse — ArchUnit ist für Kotlin transparent, weil es auf Bytecode-Ebene arbeitet:

Die that()-Klauseln filtern, was du betrachten willst:

Die klassische Schichten-Regel: Controller → Service → Repository, niemals umgekehrt.

ArchUnit hat eingebaute Pattern für die kanonischen Architekturen: layeredArchitecture(), onionArchitecture(). Kompakt und lesbar.

Wenn du Hexagonal aus B2/L02 umsetzt, ist das die zentrale Regel:

Strukturelle Konventionen einfangen:

Klein, aber als Hygienemarker wichtig:

.as("Logger statt System.out verwenden")

ArchUnit hat dafür Frozen Rules:

Der Mutation-Score ist getötete Mutanten geteilt durch alle Mutanten. Eine ehrliche Metrik dafür, ob deine Tests Verhalten prüfen oder nur ausführen.

Auch wenn Coverage allein irreführend ist (Sektion 6), ist ein Mindest-Schwellenwert im Build trotzdem sinnvoll — als untere Grenze.

Gradle bietet dafür Dependency Locking und das failOnVersionConflict()-Resolution-Strategy-Flag:

Scannt deinen Klassenpfad gegen die National Vulnerability Database (NVD) und meldet Dependencies mit bekannten CVEs.

renovate.json minimal:

.github/workflows/ci.yml:

Streaming-Operatoren auf Flux:

Du kannst explizit umschalten:

Die Variante, die dir am vertrautesten aussieht, sind annotierte Controller mit reaktiven Return-Types:

WebFlux hat eine zweite, funktionale Routing-Variante ohne Annotations:

RestTemplate und RestClient (synchron) haben in WebFlux einen reactive Bruder: WebClient. Wenn du in einem WebFlux-Endpoint einen externen Call machst, muss der reactive sein, sonst pinnst du den Event-Loop-Thread:

Spring Security hat ein reactive Pendant. Konzepte sind dieselben (Filter-Chain, Authentication, Authorization), die API ist andere Annotationen und andere Konfigurations-Klassen:

Server-Sent Events (SSE), WebSockets, langlebige Streams — also Endpoints, die eine einzelne Connection minutenlang halten und dabei laufend Daten senden. Reactive ist hier semantisch passend, weil ein Flux<T> über Zeit

Mit Coroutines + Flow wäre dieselbe Stream-Variante:

Für ein neues Projekt:

Setup im Test:

Falle: du hast einen Flux, der einen HTTP-Call macht, und subscribed zweimal (z. B. zu zwei downstream Stages). Cold-Verhalten heißt dann: zwei HTTP-Calls. Wenn du das nicht wolltest, brauchst du .cache() oder .publish()

Reactor bietet als Alternative Context:

spike-reactive/build.gradle.kts:

Vorschlag: starte einen WireMock-Container, der auf GET /users/{id} mit einer Latenz von 200 ms antwortet.

wiremock/mappings/users.json:

Endpoint GET /aggregate/{n} — aggregiert n Calls an WireMock und gibt die User zurück.

Endpoint analog, aber reactive:

Alternative mit suspend fun plus Coroutines-Bridge:

Alternative mit Flow<T>:

die zusammenarbeiten:

jakarta.persistence. ist nur die offensichtlichste Änderung.

Open-Class. Beide zusammen sind in Boot-Kotlin-JPA-Projekten

CustomerRepository. Explizit. Kein Lazy-Loading.

von Data JDBC übernimmt Cascade und Orphan-Removal automatisch.

val customerId: Long

val roleId: Long,

Die @Transactional-Annotation ist davon abstrahiert.

Starte mit einem frischen Boot-4-Kotlin-Projekt. build.gradle.kts:

application.yml:

sehen, wo Lazy-Loading zuschlägt.

fun findByEmail(email: String): User?

fun listAddresses(id: Long): List<Address> = get(id).addresses.toList()

UserResponse:

Bearbeite build.gradle.kts:

Entities umschreiben:

application.yml:

schema.sql neu (Data JDBC nutzt kein ddl-auto):

Service anpassen — kein Lazy-Loading mehr, alle Daten werden zusammen

addresses = user.addresses.map { AddressDto(it.street, it.zip, it.city) }.toList(),

Drei Dateien (Standard-Initializr-Output, gekürzt):

runApplication<HelloApplication>(args)

fun hello(): Map<String, String> = mapOf("message" to "Hello, Spring")

Zwei Dateien:

call.respond(mapOf("message" to "Hello, Ktor"))

Schreib dir die beiden Werte in eine Datei notes.md im ktor-hello-Verzeichnis, mit jeweils zwei bis drei Stichworten Kontext (Maschine, JDK-Version, warmer/kalter Build). Beispiel:

Bau aus beiden Projekten ein deployment-fähiges JAR:

Öffne src/main/kotlin/com/example/hello/Routing.kt (oder wie der Initializr die Datei genannt hat — meist Routing.kt oder direkt in Application.kt). Ändere den Endpoint so, dass er statt String einen JSON-Body zurückgibt

Das ist der vollständige Build-File, den ich in dieser Lektion durchgehe — alles, was später dazukommt, wird darauf aufbauen.

Die application-Konfiguration zeigt auf die JVM-Klasse, die Gradle als Entry Point ausführen soll. Wichtig: das ist nicht der Klassen-Pfad in deinem Kotlin-Code, sondern die kompilierte JVM-Klasse — Kotlin hängt an Top-L

Das Routing in Ktor ist ein Kotlin-Builder. Du baust dir einen Baum aus route { ... }-Blöcken auf, und an den Blättern hängen get, post, put, delete und Co.

Wenn du mehrere Endpunkte unter einem gemeinsamen Pfad-Prefix hast, fasst du sie in einem route(...)-Block zusammen:

Das ist deutlich näher an dem, was in Spring Boot ein Controller mit @RequestMapping("/api/v1/users") auf Klassen-Ebene macht — nur eben als verschachtelter Block statt als Annotation-Hierarchie.

Drei Pattern, die du in der Praxis ständig brauchst.

Default ohne expliziten Status ist 200 OK. Du kannst dir import io.ktor.http.HttpStatusCode.Companion. ans Datei-Top setzen, dann schreibst du Created statt HttpStatusCode.Created.

Das eingebaute Routing über String-Pattern (get("/users/{id}")) ist flexibel, aber typunsicher. Wenn du den Pfad umbenennst oder einen Parameter dazunimmst, merkst du das erst zur Laufzeit. Das Resources-Plugin liefert d

Das ist die Standard-Konvention: eine Top-Level-Klasse für /users, eine genestete Klasse für /users/{id}. Die parent-Referenz hängt die Sub-Ressource an die Eltern-Route.

Der Handler-Block bekommt die deserialisierte Ressource als Parameter rein, mit typisierten Feldern. resource.id ist ein Long, kein String-mit-!!-Cast. Wenn du im Pattern id: Long schreibst und ein Aufrufer /users/abc sc

In Spring schreibst du:

In Ktor mit Resources-Plugin:

src/main/resources/application.yaml:

Damit die Konfiguration tatsächlich gelesen wird, baust du main und Modul-Setup ein bisschen um:

Im ktor-hello-Projekt:

Neue Datei src/main/kotlin/com/example/hello/Books.kt:

Öffne Application.kt (oder die Datei, in der dein Application.module() lebt) und bau das Routing wie folgt um:

Im zweiten Terminal:

In IntelliJ Ultimate kannst du eine .http-Datei anlegen, in der alle Aufrufe stehen — bequemer als curl in der Shell. Datei requests/books.http:

Du musst das nicht selbst bauen — Ktor bringt für alles, was du in den ersten Wochen brauchst, fertige Plugins mit. Du installierst sie, gibst ihnen Konfiguration, und sie hängen sich in die Request-Pipeline ein.

Damit call.receive<T>() und call.respond(obj) JSON sprechen können. Ohne ContentNegotiation kennt Ktor nur Strings und Byte-Arrays.

Pro Request eine Log-Zeile mit Methode, Pfad, Statuscode, Dauer. Plus optional MDC-Felder (Request-ID, User-ID, Tenant), die du dann in jeder Log-Zeile des Handlers automatisch siehst.

Damit die requestId in jeder Log-Zeile sichtbar wird, brauchst du ein Logback-Pattern wie:

Dein Backend läuft auf api.example.com, dein SPA auf app.example.com. Ohne CORS-Header lehnt der Browser deinen Request mit „blocked by CORS policy" ab.

In Spring nutzt du @ControllerAdvice und @ExceptionHandler, um Exceptions zentral in HTTP-Responses umzuwandeln (siehe B2/L11). In Ktor heißt das Pendant StatusPages.

JSON-Responses bei 1–500 KB profitieren stark von Compression. Mobile-Clients mit knappem Datenvolumen, langsame Netze, hohe Latenz — überall lohnt sich der Trade-off CPU-für-Bandbreite.

Wenn dein Backend öffentlich erreichbar ist, willst du, dass ein Aufrufer dir nicht mit 10.000 Requests pro Sekunde den Dienst lahmlegt. Auch ohne böse Absicht — ein verbuggter Mobile-Client in einer Retry-Schleife reich

Wenn ich ein neues Ktor-Projekt starte, sieht der Plugin-Teil meistens so aus:

Vier neue Dependencies in build.gradle.kts:

Datei src/main/resources/logback.xml:

Im Application.module() den bestehenden ContentNegotiation-Block ersetzen:

Im Modul (vor routing { ... }):

Bonus: Schick einen Health-Check-Request (falls du /health aus L02-Lektion noch drin hast) und vergewissere dich, dass diese Zeile nicht geloggt wird — der filter-Block schließt sie aus.

Server neu starten. Test mit einem simulierten Preflight-Request:

Erwartung im Response-Header:

Im Modul (vor routing { ... }):

Im BookRepository-basierten Routing den null-Branch durch eine Exception ersetzen, damit der zentrale Handler greift:

call.respond(HttpStatusCode.NoContent)

Schau dir deinen Application.module()-Block am Ende an. Die Reihenfolge sollte ungefähr so sein:

In Ktor 3.3 sah ein typischer Endpoint so aus:

In 3.4 fügst du dem gleichen Endpoint einen openapi-Block hinzu:

Der Plugin sitzt im Gradle-Block:

Im Code aktivierst du die Auslieferung:

Annotationen.

Das wird zu:

Eine gut beschriebene Operation hat vier Dinge:

schreibst du:

In Spring Boot (B3/L13) machst du dasselbe mit SpringDoc OpenAPI:

Profile-Check:

In build.gradle.kts: