Application Modules and Boundary Verification
Define and enforce module boundaries with Spring Modulith's structure verification and documentation.
Why Module Boundaries Matter
A Spring Boot monolith tends to rot: any class can @Autowired any other, and over time everything depends on everything. Spring Modulith brings discipline by treating top-level packages under your main application package as application modules.
- Each direct sub-package of the main package is one module.
- Code inside a module's root package and a special
apisub-package is public. - All other nested packages are internal and may not be referenced from other modules.
This lets you keep a single deployable while enforcing the boundaries you would get from microservices.
A Modular Package Layout
Consider an e-commerce app with the main class in com.shop. Each business concern becomes a direct sub-package. Spring Modulith infers the modules order, inventory, and notification from this structure alone — no XML, no annotations required.
Classes directly in com.shop.order are the module's public API; classes in com.shop.order.internal are hidden from other modules.
com.shop
├── ShopApplication.java
├── order
│ ├── OrderService.java // public API
│ └── internal
│ └── OrderRepository.java // internal
├── inventory
│ ├── InventoryService.java
│ └── internal
│ └── StockLevel.java
└── notification
└── NotificationService.javaAll lessons in this course
- Application Modules and Boundary Verification
- Internal Application Events and Listeners
- Transactional Event Publication and Outbox
- Module Integration Testing and Scenarios