Practical advice for building glorious monoliths
summary
Built a single deployable "glorious monolith" for a Norway scaleup instead of microservices, avoiding a 60–70k‑line single file and an 11‑file change ripple; uses schemas per module with separate DbContexts (Entity Framework), a shared kernel for value objects and typed IDs, and mediator + domain events for sync intra‑module flows while pushing inter‑module work to async queues (Hangfire, MassTransit, Brighter). Boundaries come from event storming, modules register via IRegisterModule, and automated tests enforce allowed references.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 2:26Defining the monolith
- 5:08Key concepts
- 8:43Setting boundaries
- 12:30Event storming
- 16:01Identifying contexts
- 19:44Domain inquiry
- 24:06Monolith vs microservices
- 26:11Structuring code
- 30:15Shared kernel
- 31:33Data persistence
- 35:18Module registration
- 40:20Inter-module communication
- 47:00Domain events
- 50:58Asynchronous messaging
- 55:21Verifying architecture
- 59:30Q&A
related talks
01h 02mBuilding that glorious monolith. And carving it too.
58mBuilding that glorious monolith. And carving it too.
57mModularizing the Monolith
50mMajestic Modular Monoliths
23mMicroservices within a Monolith
39mTaming Monoliths Without Microservices
25mBreak up Monoliths and lay them to REST!
01h 29mMonolithic Delivery