0PricingLogin
Spring Boot 4 Complete Guide · Lesson

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 api sub-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.java

All lessons in this course

  1. Application Modules and Boundary Verification
  2. Internal Application Events and Listeners
  3. Transactional Event Publication and Outbox
  4. Module Integration Testing and Scenarios
← Back to Spring Boot 4 Complete Guide