Spring Modulith With Spring Boot 4: Enforce Module Boundaries Before You Split Into Microservices

Most teams split a monolith to get clean boundaries, and pay for a network, a message broker and distributed failures to get them. Spring Modulith gives you the boundaries inside one Spring Boot app, with a test that fails when a module reaches into another.

Four modules inside one Spring Boot app, each with an open API and a locked internal package, connected by one-way events that a registry keeps safe across a crash.

This is the whole test:

class ModularityTests {
    @Test
    void verifiesModularStructure() {
        ApplicationModules.of(ShopApplication.class).verify();
    }
}

Run it against a Spring Boot codebase that has been growing for two years, and it usually fails with a list. Each line names a class that uses something inside another package it was never meant to touch. The order code calls a repository that belongs to inventory. The shipping code reads an order entity directly. Order needs payment, and payment needs order.

Nobody decided on those dependencies. Each one was a reasonable shortcut on the day it was written. Together they are why the codebase feels hard to change, and they are the main reason teams say “we need microservices”. I used to believe that too: that clean boundaries need a network between them. They do not. They need something that fails the build when a boundary is crossed. A network is one very expensive way to get that. A…