Practical advice for building glorious monoliths
summary
Argues for modular monoliths as a practical alternative to microservices, showing a Commerce codebase that uses DDD bounded contexts, module discovery via reflection, and per-module EF DbContexts kept in one database using schemas to isolate data. Demonstrates domain events dispatched through Mediator, persisted with the outbox pattern, and async delivery with MassTransit/RabbitMQ or Azure Service Bus. Shows integration tests running SQL Server in testcontainers, migration practices, and how these conventions make refactoring and boundary changes easier.
AI-written summary · about
chapters (13)
- 0:00🚀 Introduction to Building Modular Monoliths
- 5:10Defining what makes a monolith modular
- 17:00Common pitfalls in monoliths: From "big ball of mud" to structure
- 25:00Cohesion and Coupling: How to achieve balance
- 37:00Microservices vs Monoliths: An honest comparison
- 46:00The role of Domain-Driven Design in creating clear boundaries
- 1:03:00Introduction to Event Storming for defining module boundaries
- 1:17:00Practical coding examples for organizing your code
- 1:32:00Managing persistence and using database schemas effectively
- 1:44:00How to structure your codebase to maintain clarity
- 1:52:00The importance of reducing complexity over time
- 2:10:00Glenn’s tips for making your monolith future-proof
- 2:20:00Conclusion and final thoughts on building modular monoliths
related talks
43mModular Monoliths: The Architecture That Scales w Your Domain
53mCrafting a self-documenting Modular Monolith with DDD principles (theory not included)
52mBuilding monolith applications that could scale to microservices..
56mBuilding That Glorious Monolith. And Carving It Too
46mLove Your Monolith
45mBuilding Monoliths that Could Scale (Easily) to Microservices (If They Need)
45mHow I learned to stop worrying and love the monolith
45mUsing DDD To Decompose Your Monolith