The modular monolith
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
structure one deployable into modules with real boundaries.
Planned topics
- One deployment, several modules (
catalog,orders,inventory,payments), each with its own domain and data. - Each module exposes a small public API (package or interface); everything else is internal.
- Enforce boundaries by tooling: Java modules, separate Gradle/Maven modules, or ArchUnit tests, not by good intentions.
- Modules do not share tables freely; each owns its schema or tables and others call its API.
- Spring Modulith is one option to verify structure and publish events between modules (verify version before recording).
- Cheaper than microservices and the natural step before splitting.
Draft outline details
Demonstration
a package layout orders/api, orders/internal, plus an ArchUnit rule forbidding inventory from importing orders.internal.
Check your understanding
What makes a module boundary real?
Show answer
A tool or build rule that fails when it is crossed.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.