Spring Boot: Auto-Configuration, Starter und Profile

Spring Boot erkennt anhand des Classpaths, der vorhandenen Beans und der Konfiguration, welche Infrastruktur sinnvoll ist. Das ist keine Magie, sondern bedingte Konfiguration. Starter bündeln passende Abhängigkeiten, Auto-Configuration registriert passende Beans, Properties steuern Verhalten.

Im Enterprise-Umfeld ist Boot wertvoll, weil es Standards reproduzierbar macht. Gleichzeitig muss jedes Team wissen, wie Auto-Konfiguration geprüft und übersteuert wird.

@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
  </dependency>
</dependencies>

Viele einzelne @Value-Felder sind schwer zu validieren und schlecht dokumentiert. Für Enterprise-Anwendungen sind typsichere @ConfigurationProperties besser: sie bilden technische Konfiguration als eigenes Objekt ab, können validiert und getestet werden.

@ConfigurationProperties(prefix = "billing")
@Validated
public record BillingProperties(
    @NotBlank String baseUrl,
    @Min(1) int connectTimeoutSeconds,
    boolean dryRun
) {}

billing:
  base-url: https://billing.internal
  connect-timeout-seconds: 3
  dry-run: false

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

Profiles sind geeignet, um Umgebungsvarianten zu aktivieren. Sie sind nicht geeignet, um Fachlogik zu verzweigen. Unterschiedliche technische Infrastruktur darf über Profile variieren; fachliche Regeln sollten über Konfiguration, Strategien oder Daten modelliert werden.