Spring Modulith für modulare Monolithen

• Application Modules über Package-Struktur.
• Published Language und erlaubte Abhängigkeiten.
• Modul-Verifikation in Tests.
• Application Events zwischen Modulen.
• Dokumentationssnippets und Modul-Observability.

• Du willst fachliche Module schneiden, aber nicht sofort deploybare Microservices.
• Du modernisierst einen Monolithen und brauchst klare Grenzen.
• Du willst Architekturregeln automatisiert testen.

• Package-Struktur spiegelt keine fachliche Domäne.
• Module greifen direkt auf fremde Repositories zu.
• Events ersetzen klare Use-Case-Schnittstellen an falscher Stelle.

Ein Big-Ball-of-Mud-Monolith wird zuerst in Modulith-Module geschnitten; erst stabile Module werden später Kandidaten für Services.

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.

@ApplicationModule(
    displayName = "Order Management",
    allowedDependencies = { "inventory :: api", "billing :: api" }
)
package com.example.order;

import org.springframework.modulith.ApplicationModule;

// Modulprüfung
class ArchitectureTests {
    @Test
    void verifiesModularStructure() {
        ApplicationModules.of(OrderApplication.class).verify();
    }
}

• 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?