Claude Code Spring Boot: Java-Backends und REST-APIs mit KI entwickeln

Spring Boot ist seit Jahren der Standard für Java-Enterprise-Backends. Controller, Services, Repositories, Security-Konfigurationen, Transaktionsverwaltung — ein gut strukturiertes Spring-Projekt hat viele bewegliche Teile, und jeder Entwickler kennt die Situation: Man weiß genau, was gebaut werden soll, aber die reine Schreibarbeit für Boilerplate-Code kostet Zeit, die man lieber in Architekturentscheidungen investieren würde.

Claude Code ist hier ein idealer Partner — nicht weil es Spring Boot besser kennt als ein erfahrener Java-Entwickler, sondern weil es den gesamten Projektkontext gleichzeitig liest: bestehende Entities, laufende Konventionen, verwendete Abhängigkeiten, vorhandene Tests. Was dabei entsteht ist kein generischer Boilerplate, sondern Code der zum bestehenden Projekt passt.

1. Controller und REST-Endpunkte generieren

Ein typischer Einstiegspunkt: Du hast eine neue Ressource — zum Beispiel Order — und brauchst einen vollständigen REST-Controller mit CRUD-Operationen. Statt jede Methode einzeln zu tippen, gibst du Claude Code den Kontext und lässt es die Arbeit erledigen:

claude "Erstelle einen REST-Controller für Order-Ressourcen.
Schau dir die vorhandenen Controller (CustomerController,
ProductController) an und halte dich an deren Konventionen.
Die Order-Entity liegt in com.example.shop.entity."

Claude Code liest daraufhin die vorhandenen Controller, erkennt das verwendete Muster — ob @RestController mit @RequestMapping auf Klassen-Ebene oder mit expliziten Methoden-Annotationen — und erstellt den neuen Controller in exakt demselben Stil. Responsetypen, Exception-Handling, Validierungsannotationen wie @Valid und @NotNull: alles wird übernommen, nicht neu erfunden.

@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {

    private final OrderService orderService;

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<OrderDto> getOrder(@PathVariable Long id) {
        return ResponseEntity.ok(orderService.findById(id));
    }

    @PostMapping
    public ResponseEntity<OrderDto> createOrder(
            @Valid @RequestBody CreateOrderRequest request) {
        OrderDto created = orderService.create(request);
        URI location = URI.create("/api/v1/orders/" + created.getId());
        return ResponseEntity.created(location).body(created);
    }

    @PutMapping("/{id}")
    public ResponseEntity<OrderDto> updateOrder(
            @PathVariable Long id,
            @Valid @RequestBody UpdateOrderRequest request) {
        return ResponseEntity.ok(orderService.update(id, request));
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteOrder(@PathVariable Long id) {
        orderService.delete(id);
        return ResponseEntity.noContent().build();
    }
}

2. Service-Layer und Dependency Injection strukturieren

Der Service-Layer ist das Herzstück jeder Spring-Anwendung. Hier liegt die Geschäftslogik, hier werden Transaktionen verwaltet, hier werden Daten transformiert. Und hier entscheidet sich, ob eine Anwendung langfristig wartbar bleibt.

Claude Code hilft dabei, den Service-Layer sauber zu strukturieren — und zwar abgestimmt auf das, was bereits im Projekt vorhanden ist:

claude "Erstelle den OrderService für den OrderController.
Schau dir CustomerService und ProductService an wie die
Transaktionen und Exception-Handling dort gelöst sind.
Verwende dieselben Custom-Exceptions wie ResourceNotFoundException."

Das Ergebnis berücksichtigt automatisch @Transactional-Annotationen am richtigen Ort, verwendet Constructor-Injection statt Field-Injection (weil das in den anderen Services so ist), und wirft die projektspezifischen Custom-Exceptions statt generischer RuntimeException.

Besonders wertvoll ist Claude Code bei der Frage, wohin welche Logik gehört. Wenn du unsicher bist, ob Validierungslogik in den Controller oder in den Service gehört, oder ob eine Transformation im Service oder im Mapper stattfinden sollte:

claude "Ich bin unsicher: Soll die Prüfung ob ein Produkt
noch auf Lager ist im OrderService oder im ProductService
liegen? Was macht mehr Sinn für unsere Architektur?"

Claude Code liest beide Services, versteht die Verantwortlichkeiten und gibt eine begründete Empfehlung — mit Verweis auf das Single-Responsibility-Prinzip und dem konkreten Kontext eures Projekts.

3. JPA-Repositories und Datenbankentities erstellen

Spring Data JPA ist mächtig — aber JPQL-Queries schreiben kostet Zeit, und die Syntax für komplexere Abfragen ist nicht immer intuitiv. Claude Code generiert JPA-Entities und Repository-Methoden, die sofort funktionieren:

claude "Erstelle eine Order-Entity mit Beziehung zu Customer
(Many-to-One) und OrderItems (One-to-Many). Schau wie andere
Entities Beziehungen definieren. Erstelle auch das Repository
mit Methoden: findByCustomerId, findByStatusAndCreatedAtAfter,
und eine JPQL-Query für alle offenen Orders über einem
bestimmten Gesamtbetrag."

Das Ergebnis ist eine vollständig annotierte Entity mit korrekten Cascade-Typen, Fetch-Strategien (Lazy vs. Eager wo sinnvoll) und einem Repository das sowohl von Spring Data JPA abgeleitete Methodennamen als auch explizite @Query-Annotationen für komplexere Abfragen kombiniert:

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {

    List<Order> findByCustomerId(Long customerId);

    List<Order> findByStatusAndCreatedAtAfter(
        OrderStatus status, LocalDateTime since);

    @Query("SELECT o FROM Order o WHERE o.status = 'OPEN' " +
           "AND o.totalAmount > :minAmount " +
           "ORDER BY o.createdAt DESC")
    List<Order> findOpenOrdersAboveAmount(
        @Param("minAmount") BigDecimal minAmount);
}

4. Spring Security — Authentication und Authorization mit KI konfigurieren

Spring Security ist mächtig und flexibel — was auch bedeutet, dass Konfigurationsfehler subtil und schwer zu debuggen sind. Eine falsche Reihenfolge in der Filter-Chain, ein vergessenes csrf().disable() für REST-APIs, eine zu permissive oder zu restriktive Authorize-Regel — all das führt zu Problemen, die nicht immer sofort als Security-Probleme erkennbar sind.

Claude Code hilft auf zwei Ebenen: beim Schreiben der Konfiguration und beim Verstehen warum etwas nicht funktioniert.

claude "Konfiguriere Spring Security für unsere REST-API:
- JWT-basierte Authentication
- /api/v1/auth/** ist public
- /api/v1/admin/** nur für ROLE_ADMIN
- Alles andere authentifiziert
- CORS für localhost:3000 im Entwicklungsmodus"

Bei Security-Problemen ist Claude Code besonders nützlich, weil Spring Securitys Fehlerausgaben oft wenig über die eigentliche Ursache sagen. Ein 403 Forbidden kann viele Ursachen haben. Claude Code analysiert die vollständige Security-Konfiguration und zeigt, welche Regel greift:

claude "POST /api/v1/orders gibt 403 zurück obwohl der User
eingeloggt ist und ROLE_USER hat. Analysiere meine Security-
Konfiguration und finde warum der Request geblockt wird."

5. Maven/Gradle Build-Probleme lösen und Abhängigkeiten verstehen

Dependency-Konflikte in Spring-Projekten gehören zu den frustrierendsten Debugging-Erlebnissen: Zwei Bibliotheken wollen unterschiedliche Versionen derselben transitiven Abhängigkeit, Spring Boot’s BOM (Bill of Materials) managet Versionen automatisch, aber manchmal kollidiert das mit einer manuell gesetzten Version.

Maven-Fehlermeldungen sind nicht immer selbsterklärend. Claude Code kann sie direkt lesen und interpretieren:

mvn dependency:tree 2>&1 | claude "Gibt es Versionskonflikte?
Was sind die problematischen Abhängigkeiten?"

Oder bei Build-Fehlern:

mvn package 2>&1 | claude "Was ist der Fehler und wie behebe ich ihn?"

Claude Code versteht den Unterschied zwischen einem Compile-Error, einem Test-Fehler und einem Packaging-Problem — und gibt gezielte Lösungen statt generischer Hinweise. Bei Gradle-Projekten funktioniert dasselbe Muster:

./gradlew build 2>&1 | claude "Analysiere den Build-Fehler."

6. JUnit- und Mockito-Tests mit Claude Code schreiben

Tests für Spring-Komponenten zu schreiben ist oft mühsam — nicht weil die Tests komplex sind, sondern weil das Setup (Mocks anlegen, Spring-Context konfigurieren, Test-Daten vorbereiten) viel Schreibarbeit bedeutet. Claude Code nimmt diese Arbeit ab.

claude "Schreibe JUnit 5 Tests für OrderService.
Mocke OrderRepository und CustomerRepository mit Mockito.
Teste: createOrder (Happy Path), createOrder mit nicht
existierendem Customer (ResourceNotFoundException), und
getOrder für nicht gefundene Order."

Claude Code liest den OrderService, versteht welche Abhängigkeiten gemockt werden müssen, und erstellt vollständige Tests mit aussagekräftigen Test-Namen, sinnvollen Test-Daten und korrekten Assertions:

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    private OrderRepository orderRepository;

    @Mock
    private CustomerRepository customerRepository;

    @InjectMocks
    private OrderService orderService;

    @Test
    @DisplayName("createOrder: legt Order an wenn Customer existiert")
    void createOrder_happyPath() {
        Customer customer = new Customer(1L, "Max Mustermann");
        CreateOrderRequest request = new CreateOrderRequest(1L, List.of());

        when(customerRepository.findById(1L))
            .thenReturn(Optional.of(customer));
        when(orderRepository.save(any(Order.class)))
            .thenAnswer(inv -> {
                Order o = inv.getArgument(0);
                o.setId(42L);
                return o;
            });

        OrderDto result = orderService.create(request);

        assertThat(result.getId()).isEqualTo(42L);
        verify(orderRepository).save(any(Order.class));
    }

    @Test
    @DisplayName("createOrder: wirft ResourceNotFoundException wenn Customer fehlt")
    void createOrder_customerNotFound() {
        when(customerRepository.findById(99L))
            .thenReturn(Optional.empty());

        assertThrows(ResourceNotFoundException.class,
            () -> orderService.create(new CreateOrderRequest(99L, List.of())));

        verify(orderRepository, never()).save(any());
    }
}

Für Integrationstests mit @SpringBootTest oder @WebMvcTest ist Claude Code ebenso hilfreich — besonders bei der Frage, welcher Test-Slice für welchen Zweck geeignet ist:

claude "Was ist besser für Tests meines Controllers:
@WebMvcTest oder @SpringBootTest? Erkläre den Unterschied
im Kontext unseres Projekts."

“@WebMvcTest lädt nur den Web-Layer — schnell, aber deine Services müssen gemockt werden. @SpringBootTest lädt den vollständigen Context — langsamer, aber realistischer. Für Controller-Tests die nur HTTP-Verhalten prüfen: @WebMvcTest. Für End-to-End-Flows durch mehrere Layer: @SpringBootTest mit @Sql für Testdaten.”

Claude Code Spring Boot ist kein Ersatz für tiefes Java-Know-how — aber es ist ein Multiplikator. Die Zeit die du für Boilerplate-Code, JPQL-Syntax-Recherche und Security-Debugging aufwendest, schrumpft dramatisch. Was übrig bleibt ist die Arbeit, die wirklich Denken erfordert: Architekturentscheidungen, Domänenmodellierung, Performance-Optimierung.

Verwandte Artikel die auf diesem Thema aufbauen:

• Claude Code Debugging — Stack Traces analysieren und Root-Cause finden
• Claude Code für Python-Projekte — wie du Claude Code in Python-Workflows einsetzt