Modular Monolith

A modular monolith keeps one deployable unit but enforces strong internal boundaries. Each domain module owns its models, logic and interfaces. This keeps development simple while reducing coupling.

When it fits

• Teams want the speed of a monolith with clearer separation of concerns
• The product has multiple domains but shared data and release cadence

Risks

• Requires discipline to maintain boundaries
• Poor boundaries drift into a distributed monolith if you later split services

Real‑world examples

• Shopify publicly describes evolving its large Rails monolith into a modular monolith to improve scale and ownership before carving out a few services
• GitLab maintains domain‑oriented components within its monolith to manage complexity

Practical tips

• Enforce module boundaries at build time and through code reviews
• Use internal interfaces to decouple modules from each other’s data