Spring Modulith Modular Monolith

Structure the deployable as business modules with verified boundaries instead of a layered package tree, and keep the extraction option open by never letting two modules share a table. Spring Modulith detects the modules, verifies the dependency graph, and fails a test on a cycle or an undeclared access, which turns organised-by-feature from a convention into a build failure.

When to use

• Deciding where the module boundary sits, or a cycle exists between packages, masked by spring.main.allow-circular-references.
• Two features share entities and constants, a common or util package is a dumping ground, or a module had to make its whole package public to expose one type.
• Deciding between a direct call and a module event, or whether a module is ready to become a service.

When not to use

• Which ring a class belongs to belongs to spring-boot-clean-architecture; aggregate design to spring-boot-ddd.
• Port interfaces and adapter wiring belong to spring-boot-hexagonal-architecture.
• Container images and build output belong to spring-boot-docker; pipeline stages and promotion belong to spring-boot-ci-cd.

Ownership and sibling boundaries

This skill owns module boundaries, their declared allowed dependencies, exposed named interfaces, module events, and the extraction gate.