Search for a command to run...
Series
This series is about building modular monoliths that hold up under real pressure. Not textbook examples or folder-based "modules", but systems with enforced boundaries, clear ownership, and predictable change. Parts 1-5
If you’ve followed this series so far, you’ve done the hard structural work. You’ve enforced real module boundaries.You’ve organised behaviour into vertical slices.You’ve isolated data with separate DbContexts.You’ve stopped modules from chatting lik...
Once you’ve enforced boundaries, adopted vertical slices, and given each module its own DbContext, a new tension appears almost immediately. Modules are now properly isolated. They own their data. They commit independently. They even fail independent...
By the time you’ve enforced real module boundaries and organised behaviour using vertical slices, you run head-first into the next uncomfortable question: If modules are truly independent, why are they still sharing a DbContext? This is where most ...
In the first post of this series, I talked about enforcing real module boundaries. Assemblies. Internals. Contracts. The boring but essential stuff that stops your modular monolith collapsing into a shared-nothing-in-name-only mess. But once you’ve d...
There’s a moment that happens to most of us at some point in our careers. You’ve done “everything right”. You’ve split the solution into folders called Modules. You’ve got namespaces that look clean. You might even have separate projects. And yet, si...
