Ein Modulith ist eine Architekturform, in der eine Anwendung in einem einzigen Deployment-Prozess läuft, intern aber klar in fachliche Module gegliedert ist. Module haben definierte Schnittstellen, eigene Datenmodelle und teils eigene Persistenzschichten – aber sie teilen sich die Laufzeit eines Monolithen.
In der Praxis wird der modulare Aufbau durch Konzepte wie "package by feature", DDD-Bounded-Contexts, interne Schnittstellen, Modul-Tests und gezielte Architekturregeln (z. B. ArchUnit, dotnet-arch-tests) erzwungen. Frameworks wie Spring Modulith oder die in .NET aufkommenden "vertical slice architectures" unterstützen den Stil.
Einsatzzweck ist die Kombination der Vorteile von Monolithen (einfachere Operationen, geringere Verteiltheit) mit denen modularer Architekturen (klare Verantwortlichkeit, Testbarkeit, Optionen für spätere Microservice-Extraktion). Insbesondere Teams, die Microservice-Komplexität nicht von Anfang an tragen wollen, nutzen Modulithen als Zwischenschritt.
Der Begriff wurde durch Diskussionen rund um Microservices-Skepsis ab 2018 prominent, prominent gemacht durch Sam Newmans und Martin Fowlers "MonolithFirst"-Artikel sowie durch Oliver Drotbohms Spring-Modulith-Projekt. In der .NET-Community greift unter anderem Steve Smith das Thema mit "clean architecture, modular monolith" auf.
In der Praxis ist der Modulith oft die ehrlichere Architektur: Viele Teams brauchen die Verteiltheit von Microservices nicht, profitieren aber stark von klaren Modulgrenzen. Diese Erkenntnis spricht sich erst seit einigen Jahren durch – als Reaktion auf zahlreiche überzogene Microservices-Initiativen, die mit Modulithen vermutlich zufriedener gewesen wären.