Building that glorious monolith. And carving it too.
summary
Argues for starting with a modular monolith that uses Domain Driven Design so each feature is a boxed domain with clear API-like boundaries; implements per-feature EF Core DbContext and database schema ownership to prevent cross-feature table access; uses MediatR handlers and in-process domain events (with outbox for important messages) to integrate features; enforces architectural rules with namespace/compile-time analyzers; team size is ~5 and the app deploys multiple times a day — carving a feature into a service becomes a small, well-defined job.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:08Monoliths vs microservices
- 2:10Why we chose monolith
- 7:26Monolith problems
- 9:55Complexity dampening
- 12:03Domain-driven design in monolith features
- 15:55Features as modules
- 18:22Use case handlers
- 22:59Endpoint config
- 24:01Modular monolith conventions
- 26:08Features like microservices
- 26:52Feature data ownership
- 29:44DB contexts isolation
- 31:12Shared data with events
- 34:24Transaction management
- 38:21Preventing spaghetti code
- 42:24Why modularize
- 43:06When microservices fit
- 44:33Team topology
- 46:01Tech for carving
- 47:27Carving microservices
- 50:38Summary
- 53:46Q&A
related talks
01h 02mBuilding that glorious monolith. And carving it too.
01h 04mPractical advice for building glorious monoliths
58mBuild software like a bag of marbles, not a castle of LEGO®
25mBreak up Monoliths and lay them to REST!
23mMicroservices within a Monolith
57mModularizing the Monolith
37mBuilt to last: A domain-driven approach to beautiful systems
39mTaming Monoliths Without Microservices