Jede Anwendung braucht Konfiguration. Wo liegt die Datenbank? Auf welchem Port läuft der Server? Welches Datumsformat soll verwendet werden? Traditionell musste jede dieser Entscheidungen explizit getroffen und dokumentiert werden. Spring Boot geht einen anderen Weg.
“Convention over Configuration” – Konvention vor Konfiguration – bedeutet: Das Framework trifft sinnvolle Standardentscheidungen. Du konfigurierst nur, was vom Standard abweicht.
Das klingt trivial, ist aber radikal. Es verschiebt die Beweislast. Statt zu fragen “Was will ich?” fragst du “Was will ich anders?”. Die Antwort ist meist: wenig.
Schau dir die application.yaml des Arcade-Projekts
an:
spring:
application:
name: arcade-highscore-api
server:
port: 8080Vier Zeilen. Das ist die gesamte Konfiguration einer lauffähigen
Webanwendung. Aber Moment – wo ist die Tomcat-Konfiguration? Wo wird
Thymeleaf eingerichtet? Wo steht, dass statische Dateien aus
/static geladen werden?
Nirgends. Das sind Konventionen.
Spring Boot trifft hunderte Annahmen, die du nicht siehst. Einige davon:
Jede dieser Annahmen kannst du überschreiben. Aber du musst es nicht. Für 90% aller Projekte passen die Defaults.
Stell dir vor, du müsstest jede Konvention explizit konfigurieren.
Die application.yaml würde so aussehen:
# So sähe es OHNE Konventionen aus – zum Glück nicht nötig!
server:
port: 8080
servlet:
context-path: /
tomcat:
uri-encoding: UTF-8
max-threads: 200
connection-timeout: 20000
spring:
mvc:
static-path-pattern: /**
web:
resources:
static-locations: classpath:/static/,classpath:/public/
thymeleaf:
prefix: classpath:/templates/
suffix: .html
mode: HTML
encoding: UTF-8
cache: true
logging:
level:
root: INFO
pattern:
console: "%d{yyyy-MM-dd HH:mm:ss} %-5level %logger{36} - %msg%n"
jackson:
serialization:
write-dates-as-timestamps: false
indent-output: false
default-property-inclusion: non_nullDas wären über 30 Zeilen Boilerplate für Selbstverständlichkeiten. Zeit, die du besser in Geschäftslogik investierst.
Ein häufiges Missverständnis: Konventionen sind nicht mysteriös. Sie sind dokumentiert und deterministisch. Wenn du wissen willst, welche Defaults gelten, schau in die Spring Boot Dokumentation. Dort ist jede Property mit ihrem Standardwert aufgelistet.
Das ist wichtig. “Convention over Configuration” bedeutet nicht “Configuration impossible”. Es bedeutet “Configuration optional”. Du behältst die volle Kontrolle – du musst sie nur nicht immer ausüben.
Manchmal passen die Defaults nicht. Das ist normal und vorgesehen.
Der Webserver soll auf Port 9000 laufen statt 8080? Eine Zeile:
server:
port: 9000Templates sollen aus einem anderen Verzeichnis kommen? Kein Problem:
spring:
thymeleaf:
prefix: classpath:/views/Die Kunst liegt darin, zu wissen, wann eine Anpassung nötig ist – und wann du gegen den Strom schwimmst, nur weil du es kannst. Erfahrene Spring-Entwickler halten sich an Konventionen, wo immer möglich. Das macht Code vorhersehbar und wartbar.
Wenn du das Arcade-Projekt startest und die Landingpage im Browser erscheint, passiert etwas Bemerkenswertes. Du hast nie konfiguriert, dass:
index.html die Startseite istarcade.css unter /css/arcade.css
erreichbar istHomeController für Anfragen an /
zuständig istAlles davon folgt aus Konventionen. Du legst eine Datei an den richtigen Ort, gibst ihr den richtigen Namen – und es funktioniert.
Das ist die Philosophie von Spring Boot: Mach das Richtige einfach und das Falsche schwer.