Modular Monolith Architecture: Structure, Communication & Team Topology Explained

1. What Is a Modular Monolith?

Layered architecture splits code by technical responsibility (presentation, business, persistence), scattering a single business feature across multiple layers. Changing one feature requires jumping across packages. The modular monolith responds to this problem: it remains a single deployable unit but organizes code by business domain rather than technical layer.

2. Monolithic Structure vs Modular Structure

Two ways to organize modules:

Monolithic structure : All modules live in one repository, separated by namespaces or directories, and packaged together at deployment. Simplest to maintain, test, and deploy, but the convenience encourages cross‑module reuse and communication, gradually leading to a big ball of mud.

Modular structure : Each module is an independent artifact; they are composed into a single unit at deployment. Boundaries are stricter, reducing accidental cross‑module dependencies — suitable for large or complex systems. However, inter‑module dependencies introduce version conflicts and compile‑time dependency issues (jar/DLL hell).

Rule of thumb: choose modular structure when modules have few dependencies; choose monolithic structure when dependencies are many.

3. Module Communication

Peer‑to‑peer : A module directly instantiates another module's classes and calls methods. In a monolithic structure this is too easy, making architectural constraints ineffective. In a modular structure explicit dependencies are required, adding a barrier.

Mediator pattern : A mediator component acts as an abstraction layer; modules communicate only through it. This does not eliminate coupling — it shifts coupling from module‑to‑module to module‑to‑mediator — but keeps modules independent and the architecture clearer.

4. Characteristic Ratings

Strengths : Overall cost, simplicity, and modularity rate high.

Deployability and maintainability : Two stars — slightly better than layered architecture thanks to modularization.

Elasticity and scalability : One star — limited by single‑unit deployment.

Fault tolerance : One star — also limited by monolithic deployment.

4.1 Suitable Scenarios

Tight budget and timeline; a good starting point for new systems. If architectural direction is unclear, begin with a modular monolith and migrate to service‑oriented or microservices later — wiser than jumping straight into distributed architecture.

Cross‑functional teams organized by domain; each team owns a module end‑to‑end, minimizing cross‑team coordination. Especially fitting when most changes are domain‑driven.

Natural alignment with Domain‑Driven Design (DDD) because the architecture is domain‑partitioned.

4.2 Unsuitable Scenarios

Systems requiring high scalability, high availability, high fault tolerance, or high performance.

When most changes are technology‑driven. Domain‑partitioned architecture means a technical change ripples across every module, demanding heavy cross‑team coordination; layered architecture is preferable in that case.

5. Team Topology

Because modular monolith is a domain‑partitioned architecture, teams should align with domains:

Stream‑aligned teams : One team owns the full domain flow from presentation to database, matching the self‑contained nature of modules.

Enabling teams : High modularity and separation of concerns let experts introduce new modules for experiments with minimal impact on existing modules.

Complicated‑subsystem teams : Each module typically fulfills a specific domain role (e.g., payment processing); different members can focus on complex domain logic without interference.

Platform teams : High modularity enables teams to leverage common tools, services, and APIs effectively.

Caution : Technology‑siloed teams work poorly with this style. Distributing domain requirements to technical teams creates heavy communication overhead.

1. Fundamentals of Software Architecture 2nd Chapter 11