Majestic Modular Monoliths
summary
Advocates a modular monolith: keep a single deployable artifact but partition code and data by domain into module-per-JAR boundaries with one table/schema per module, and only split into separate services for scaling or tech reasons. Recommends concrete Java build and runtime practices—module-info/access rules, Maven or Gradle isolation, dependency checks—and repeatable deployment using Flyway database migrations and Boxfuse images. Argues this preserves ACID transactions and lowers operational and hiring costs compared with an immediate move to many microservices.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:11Code understanding and structure
- 7:27Monolith vs microservices
- 11:45Pros and cons
- 20:58Majestic modular monoliths
- 23:42Layered architecture issues
- 27:37Domain modeling and aggregates
- 32:34Isolating modules and dependencies
- 37:12Library dependency conflicts
- 42:11Database design and modularity
- 48:54Scalability and resources
- 54:39Async processing and languages
- 56:48Deployment and CI/CD
related talks
50mMajestic Modular Monoliths
47mModular Monoliths
43mModular Monoliths: The Architecture That Scales w Your Domain
01h 01mModular Monolith Instead of Microservices: How, When and Why
57mModularizing the Monolith
50mImplement the monolith - the one well modularized
45mImplement a Monolith. But Make It Modular with Well-Enforced Boundaries
52mMonoliths to Modular: Navigating the Transition