Modular monolith

Why: the goal or problem

Imagine a hiking app where walkers save guides and buy extras. Weekend tags risk changing billing code. The team wants clear ownership within one release, without separate services.

How: work toward a solution

One team ships Catalog, Library and Billing together; saved Hiking Guide has no tag.
Add tags to Library-owned tables; deploy app v2 with unchanged Billing. One database; cross-module table access is forbidden.
Library calls Catalog’s API in-process, then writes weekend. Failed lookup leaves no tag; retry after recovery.

Internal contracts, shared release

Illustrative example

Internal contracts, shared release

Hiking app · one team · Hiking Guide has no weekend tag

Change: add a Library tag; Billing behavior stays unchanged.

Deployment unit · 1

App v1 → App v2

Catalog
APIArticle lookup
Owned internalsCatalog-owned tables
Library
Tag feature added
APISet Hiking Guide tag: weekend
Owned internalsLibrary-owned tables + tag field
Billing
APIBehavior unchanged
Owned internalsBilling-owned tables

Library → Catalog API · In-process call

No direct access to another module's tables. Calls enter through its API.

One shared database; separate table ownership. Library changes its storage inside the common release.

Lookup succeeds → write weekend → Hiking Guide has tag weekend.
Lookup fails before writing → no tag. Report failure; retry after recovery.

A monolith subtype: one release and shared process failures. Enforce API boundaries with code rules and tests; folders alone cannot protect them.

Ownership boxes describe access rules, not database-machine counts.

Module APIs protect source and data ownership. They still share this release and process failure boundary.

What: the concept

A modular monolith combines one deployment with deliberate internal boundaries. Module APIs protect owned internals. It is still a monolith. Fowler

Enforce boundaries beyond folders; releases and process failures remain shared. Modules can use hexagonal ports.

Go further

Optional reading · separate from the overview

Selection & comparison

Choose explicit modules when ownership matters but shared releases remain acceptable. It is a disciplined form of monolith, not a third deployment topology. Microservices add independent deployment and network contracts; modules can prepare boundaries without promising an eventual split.

Applications

The hiking app lets Library own weekend tags and call Catalog through an internal API. Billing remains unchanged. The shared database contains separately owned tables; the drawing is about permitted access, not the number of database machines.

Implementation & cautions

Enforce imports and table access with tests or tooling. Avoid reaching into another module’s private data even inside one process. Shared deployment and process failure remain; module APIs do not provide network isolation or independent rollback.

Evidence

Martin Fowler: Monolith First ↗
Discusses learning service boundaries within a monolith; this example’s table-access rules are authored enforcement choices.
Checked 2026-09-27

Comparison within this category
Concept	Features	Advantages	Limitations	Suitable situations	Combination conditions
Modular monolith	Explicit module APIs within one deployment	Library changes stay behind its API	Boundaries need enforcement; releases stay shared	Clear ownership without remote calls	Can use clean or hexagonal module internals

Comparison within this category

Concept

Features

Advantages

Limitations

Suitable situations

Combination conditions

Modular monolith

Explicit module APIs within one deployment

Library changes stay behind its API

Boundaries need enforcement; releases stay shared

Clear ownership without remote calls

Can use clean or hexagonal module internals

Modular monolith

Why: the goal or problem

How: work toward a solution

Internal contracts, shared release

Deployment unit · 1

Catalog

Library

Billing

What: the concept

Go further

Apply this to your project

Discuss this idea