Blog

Monolith, Layered, or Modular? The Difference, With nopCommerce as the Example

"Monolith" gets thrown around as if it means one thing. It does not. There is a classic monolith, a layered monolith, and a modular monolith, and they are meaningfully different. The part that trips people up is that a layered monolith and a modular monolith are both well-organized. They are not the tidy-versus-messy distinction people assume. They are organized along different axes, and once you see the axis, the whole thing clicks.

nopCommerce is the best example I know for making it click, because it lands in an in-between spot: it is clearly not a classic monolith, and it is not a textbook modular monolith either. Seeing exactly why is the fastest way to understand all three.

The map

Put the styles on a line by how much internal structure they enforce.

A spectrum of four ways to organize a system, left to right by increasing internal structure and stronger boundaries. Classic monolith: one unit, few enforced boundaries. Layered monolith: one unit, sliced by technical layer. Modular monolith: one unit, sliced by business module. Microservices: many units, network boundaries.

The first three are all one deployable unit. Only microservices splits into separate units over a network. So classic, layered, and modular are all monoliths. The difference between them is entirely about how the inside is organized.

The three, defined

  • Classic monolith. One unit, organized by no strong principle. Any part can reach into any other. At its worst this is the "big ball of mud," though plenty of classic monoliths are just under-structured rather than a disaster.
  • Layered monolith. One unit, sliced horizontally into technical layers: presentation on top, business logic in the middle, data access at the bottom. Dependencies flow one way, usually downward or inward. This is the most common "organized monolith," and N-tier, onion, and clean architecture are all versions of it.
  • Modular monolith. One unit, sliced vertically into modules by business capability: a Catalog module, an Orders module, a Customers module. Each module owns its whole slice, including its own internal layers, and modules only talk to each other through defined public contracts, not by reaching into each other's internals.

Three structures at a glance. Classic: a box of scattered blocks connected by tangled lines, with no enforced boundaries. Layered: a box divided into three stacked horizontal layers. Modular: a box divided into three side-by-side vertical modules.

The one distinction that matters

Here is the crux, and it is the thing worth burning into memory. A layered monolith and a modular monolith slice the same system along different axes.

The key distinction between layered and modular, shown as two panels. On the left, a layered monolith is sliced horizontally, cut by technical concern, into presentation, business or services, and data-access layers stacked with dependencies flowing down. A single feature spans every layer. On the right, a modular monolith is sliced vertically, cut by business capability, into Catalog, Orders and Customers modules side by side, each containing its own small ui, logic and data layers. Each module owns its slice and talks to the others through a contract.

  • Layered slices horizontally, by technical concern. All the presentation code lives together, all the business logic lives together, all the data access lives together. The upside is a clean separation of technical responsibilities. The catch is that a single business feature, say "checkout," is smeared across all three layers, and nothing stops the catalog logic and the order logic from tangling together inside the business layer, because they share it.
  • Modular slices vertically, by business capability. Everything to do with orders, its screens, its logic, its data, lives inside the Orders module, behind a boundary. Another module cannot reach into it. This is essentially microservices' modularity, minus the network. It is why a well-built modular monolith is the easiest thing to later split into services: the seams are already drawn.

That is the whole difference. Layered is horizontal. Modular is vertical. Both are organized. They are organized the other way from each other.

Where nopCommerce sits, and why it is neither extreme

Now the useful part. nopCommerce is a layered monolith, and holding it up against the definitions shows exactly why it is not the other two.

Where nopCommerce sits, a layered monolith with a plugin module system. On the left, a stack of layers from top to bottom: Nop.Web and framework for presentation, Nop.Services for business logic, Nop.Data for LinqToDB and repositories, and Nop.Core for domain, caching and events, with dependencies pointing inward and enforced. On the right, a set of plugin blocks, each an isolated module that can be added or removed, described as modular extension. Two notes: it is not a classic monolith because it has enforced layers and a dependency rule, and it is not a textbook modular monolith because the core is sliced by layer, not into business modules.

Walking the definitions:

  • It is not a classic monolith. It has real, enforced structure. The projects are layered (Nop.Core, Nop.Data, Nop.Services, then the web and framework layer on top), and there is a strict dependency rule: everything points inward toward Nop.Core, which depends on nothing. That inward-pointing discipline is the onion architecture, and it is the opposite of "any part reaches into any other."
  • It is not a textbook modular monolith either. Its core is sliced by layer, not by business module. All the domain services, ProductService, OrderService, CustomerService, live together in Nop.Services and can reference each other. There is no enforced wall between "catalog" and "orders" the way a modular monolith would insist on. So the horizontal cut is the real organizing principle, not vertical modules.
  • But it does have a modular dimension: plugins. The plugin architecture is genuinely modular. A plugin is an isolated, self-contained unit you can add or remove, and it extends the system through defined extension points. That is real modularity, it is just aimed at extension rather than at partitioning the core domain.

So the precise answer is: nopCommerce is a layered monolith with a plugin-based module system. Calling it a "modular monolith" is loose, because its modularity comes from layering and plugins, not from a core split into business modules. Calling it a "classic monolith" undersells it badly, because it has more enforced structure than most codebases. It sits in the in-between, and that in-between is exactly why it is such a good teaching example.

Side by side

A table comparing the four styles across three dimensions. Classic monolith: organized by no strong principle, weak or no boundaries, deploys as one unit. Layered monolith: organized by technical layer horizontally, boundaries between layers, deploys as one unit. Modular monolith: organized by business capability vertically, boundaries between modules that are enforced, deploys as one unit. Microservices: organized by business capability, network boundaries per service, deploys as many units. A note says nopCommerce is the layered-monolith row, plus the plugin system.

Bottom line

The word "monolith" hides three different things, and the one that confuses people is that layered and modular are both organized, just along different axes. Layered cuts horizontally by technical concern. Modular cuts vertically by business capability. Classic does not really cut at all. nopCommerce is layered, with an inward dependency rule and a plugin system on the side, which is why it is neither a classic monolith nor a textbook modular one. If you can place nopCommerce correctly, you understand the whole distinction.

For more on reading nopCommerce as a system, and what a monolith does and does not teach about system design, see reading nopCommerce as a system. And if you need a developer who reasons about a codebase's architecture rather than just its features, that is the work I do. You can see examples of my nopCommerce work, or get a quote.

All posts