Building that glorious monolith. And carving it too.
summary
Argues for starting with a modular monolith built for Justify, using Domain-Driven Design and vertical-slice request/command handlers wired through Mediator/MediatR, with each feature owning its DB context and schema via Entity Framework. Uses in-process domain events, translates to integration events, and persists them with the outbox pattern before publishing to Azure Event Grid (or RabbitMQ/Service Bus). Shows how clear API-like feature boundaries and event-driven seams let teams carve services out later without breaking the system.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:06Monoliths making comeback
- 3:34Microservices vs monoliths
- 5:21Distributed computing fallacies
- 7:30Complexity in monoliths
- 9:18Coupling cohesion DDD
- 12:29Self-contained domain features
- 16:26Public APIs abstraction layers
- 20:21Command handlers vertical slices
- 25:17Feature architecture flexibility
- 28:31Data ownership schema separation
- 31:01Domain events outbox pattern
- 37:35Enforcing feature boundaries
- 40:53Tools for architectural rules
- 43:22Complexity vs maintainability
- 44:48Conway's law scaling
- 46:35When to carve microservices
- 48:46Avoid distributed monolith
- 51:19Start with monolith vs microservices
- 53:02Maintainable monoliths carving bonus
- 53:46Q&A duplicate data
- 56:56Q&A orchestration sagas
- 59:02Q&A releases multiple teams
related talks
58mBuilding that glorious monolith. And carving it too.
56mBuilding That Glorious Monolith. And Carving It Too
01h 04mPractical advice for building glorious monoliths
36mDo Proper Monoliths before You Do Microservices!
45mBuilding Monoliths that Could Scale (Easily) to Microservices (If They Need)
43mModular Monoliths: The Architecture That Scales w Your Domain
52mBuilding monolith applications that could scale to microservices..
42mDo proper monoliths before you do microservices!