A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Enforce boundaries inside a modular monolith

Turns a modular-monolith choice into enforceable code and data ownership rather than relying on folders and team discipline alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would define each module's public operations and owned data, then block direct references to its internals. Other modules call that public API or react to an internal event instead of querying its tables. Shared code stays small and foundational; business concepts should not move into a common project merely because two modules mention them. I would start with the highest-change or most tangled boundary rather than redesigning everything at once.

Full answer below

Practice focus

Module APIs, dependency rules, data ownership, internal events, transactions, architecture tests, and incremental untangling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A modular monolith needs explicit ownership even though it has one deployment. Folders alone do not prevent cross-module code and data access from creating one large dependency graph.
I would define each module's public operations and owned data, then block direct references to its internals. Other modules call that public API or react to an internal event instead of querying its tables. Shared code stays small and foundational; business concepts should not move into a common project merely because two modules mention them. I would start with the highest-change or most tangled boundary rather than redesigning everything at once.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Inside one process, module calls can remain ordinary method calls and can sometimes share a transaction deliberately. That is simpler than pretending every boundary is remote. Data ownership still matters: a reporting need can use a published read model or owned integration view instead of arbitrary joins across private tables. Architecture tests enforce project or namespace dependencies, while database permissions or schemas can strengthen high-value boundaries where practical.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Splitting into services before fixing ownership.
Using a shared project for all cross-module business models.
Calling private module handlers directly.
Publishing events without defining transaction timing.

A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement