Comparison
Modular monolithvsMonolith
Modular monolith
you kept the single deployable and made a module boundary something the build fails on when crossed.
A monolith with internal boundaries that are actually enforced — by module systems, build rules or tests — rather than merely intended. It gets you the ownership and reasoning benefits of separate services without the network, the deployment matrix or the distributed debugging. It is the usual right answer when someone proposes microservices for a fifteen-person company, because it makes the same boundary argument at a fraction of the operational cost.
Full entry →Monolith
everything ships together, so one bad line in someone else's feature blocks your release.
One deployable unit containing the whole application. It is the correct default for most systems and most teams: one place to look, one transaction, no network between your own functions. Its costs are organisational rather than technical and they arrive with headcount — coupled releases, a build everyone waits for, and a codebase where nobody can tell what they are allowed to change.
Full entry →