Spring Boot: Auto-Configuration, Starter, Profiles und Production Defaults
Spring Boot ist der produktionsorientierte Rahmen für Spring-Anwendungen. Es kombiniert Starter-Abhängigkeiten, Auto-Configuration, externe Konfiguration, Embedded Server und Actuator.
Fachliche Einordnung
Boot reduziert Boilerplate, aber es ersetzt kein Architekturverständnis. In Enterprise-Systemen muss man wissen, welche Auto-Configuration greift, wie Properties priorisiert werden und wie Produktionsprofile sauber getrennt sind.
Technische Darstellung
Kernkonzepte
- Starter als kuratierte Abhängigkeitspakete.
- Auto-Configuration über Bedingungen wie @ConditionalOnClass und @ConditionalOnMissingBean.
- Externalized Configuration mit Properties, YAML, Environment und Profilen.
- ApplicationRunner/CommandLineRunner für Startlogik.
- Actuator als Produktionssicht auf Health, Metrics und Info.
Wann einsetzen?
- Du brauchst schnell startbare Services mit reproduzierbarer Konfiguration.
- Du willst lokale Entwicklung, Test, Staging und Produktion über Profile trennen.
- Du willst Defaults nutzen, aber an kritischen Stellen bewusst eigene Beans setzen.
Typische Fehler und Risiken
- Auto-Configuration als Magie behandeln und nicht im Condition Evaluation Report prüfen.
- Produktionsgeheimnisse in application.yml committen.
- Zu viele Profile erzeugen Kombinationschaos.
Legacy- und Modernisierungssicht
Boot ersetzt häufig WAR/EAR Deployment durch ausführbare JARs oder Container Images. Alte application-server-spezifische Konfiguration wandert in Properties, Config Server oder Kubernetes Secrets.
Ausführliches Beispiel
Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
}
@ConfigurationProperties(prefix = "order.risk")
public record RiskProperties(BigDecimal maxAmount, boolean manualReview) {}
@Configuration
@EnableConfigurationProperties(RiskProperties.class)
class RiskConfiguration {
@Bean
RiskPolicy riskPolicy(RiskProperties props) {
return new AmountBasedRiskPolicy(props.maxAmount(), props.manualReview());
}
}
Checkliste für Reviews
- Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
- Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
- Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
- Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?