The Modular Monolith
Microservice discipline without the distributed pain.
The architecture most teams should reach for before microservices: one deployable, cleanly split into modules with enforced boundaries. Why the monolith-vs-microservices choice is a false binary, organizing by feature module instead of technical layer, enforcing dependencies with Spring Modulith and ArchUnit, communicating between modules via events - and keeping a well-modularized monolith as the launchpad to extract services only if you actually need to.
Lessons in this stage
- 01
The False Binary
IntermediateMonolith and microservices aren't the only options - and picking microservices too early buys distributed-systems pain for problems you don't have. The distributed monolith, the worst of both.
14 min - 02
Modules, Not Layers
IntermediateOrganize by feature/domain module (vertical slices) rather than technical layers (controllers/, services/, repos/) - so a change lives in one place and modules can become services later.
14 min - 03
Enforcing Boundaries
AdvancedA module boundary only counts if it's enforced. Public module APIs vs. internal packages, and failing the build when one module reaches into another's internals (ArchUnit, Modulith).
15 min - 04
Inter-Module Communication
AdvancedHow modules talk without becoming a tangle: a narrow public API for synchronous calls, domain events for decoupling, and why a shared database is the boundary-killer to avoid.
15 min - 05
Spring Modulith
AdvancedThe framework that makes modules first-class in Spring Boot: declaring application modules, verifying boundaries in a test, module events, and auto-generated documentation.
15 min - 06
The Launchpad to Microservices
IntermediateA well-modularized monolith is the best starting point: keep the modules until scale, team, or deployment pressure justifies extracting one into a service - then the seam is already there.
13 min