Modular Architecture¶

A structural-design method — instantiates Scalable Architecture Design

Divides a system along clean seams into parts that hide their internals behind stable interfaces, so each part can grow or change without forcing every other part to change with it.

Modular Architecture is the design discipline of choosing where to cut a system so that each part is independently changeable. Its animating idea — the one that makes it this method and not a mere org chart — is information hiding: a module exposes a stable interface and conceals everything behind it, so the rest of the system depends on the promise, never the internals. Get the seams right and change stays local; a module can be enlarged, rewritten, or replaced behind an unchanged interface. Get them wrong and you have a distributed tangle where every change ripples everywhere. This is the upstream structural move the capacity mechanisms rely on: you can only add, replicate, or distribute units cleanly if the system was cut so that a unit's responsibilities and state sit inside one boundary.

Example¶

A university's course-management platform has become a monolith where the grade-book, enrollment, and scheduling logic are entangled — a change to how waitlists work breaks grade export, because both reach into the same shared tables. The team reorganizes it modularly. They draw boundaries around three concerns — Enrollment, Grading, Scheduling — and decide what each exposes: Enrollment publishes "student is enrolled in section" and hides how waitlists, holds, and prerequisites are resolved inside it.

Now Grading depends only on the enrollment fact, not on the waitlist tables. When the registrar overhauls waitlist rules the next term, the change stays inside Enrollment; Grading and Scheduling never notice because the interface they rely on didn't move. The boundaries also let the teams work in parallel — each owns a module and coordinates with the others only at the interfaces — which is coordination bounded by design rather than by constant meetings.

How it works¶

Cut along change and responsibility, not convenience. Boundaries are placed so that things that change together live together and things that change independently are separated — the decomposition minimizes what must move when any one thing moves.
Hide internals behind a contract. Each module publishes a deliberately narrow interface and treats everything else as private, so callers cannot form dependencies on details that will later change.
Make the boundary the coordination limit. Because modules interact only through interfaces, coordination is required at the seams and nowhere else, capping how much any team or part must know about the rest.
Low coupling, high cohesion. Each module does one coherent job (cohesion) and touches others as little as possible (coupling) — the twin tests for whether a cut is a good one.

Tuning parameters¶

Boundary placement — where the cuts fall. Aligning them with axes of change keeps modules independent; misaligning them creates modules that always change together and gain nothing.
Interface breadth — how much each module exposes. Narrow interfaces hide more and change less but can be restrictive; wide ones are convenient but leak internals and re-couple.
Granularity — few large modules or many small ones. Fine granularity isolates change tightly but multiplies interfaces to manage; coarse modules are simpler but bundle unrelated concerns.
Coupling tolerance — how much cross-module dependency is allowed before a seam is redrawn. Stricter limits protect independence but demand more up-front design.
Interface stability policy — how hard an interface is to change once published (versioning, deprecation windows), trading agility against the safety that lets others depend on it.

When it helps, and when it misleads¶

Its strength is change locality: with the seams in the right place, parts evolve, grow, and get replaced independently, and coordination shrinks to the interfaces. It is the precondition for almost every capacity mechanism in this archetype — you cannot cleanly replicate or distribute what isn't cleanly bounded.

It misleads when the boundaries are drawn wrong or the interfaces are leaky. Cuts that don't match the real axes of change produce modules that must always change in lockstep — the overhead of separation with none of the independence. There is also a deep constraint on where the seams can go: a system's structure tends to mirror the communication structure of the organization that builds it, so modules that cut against team boundaries fight the org and erode.^[1] The classic misuse is drawing boundaries by superficial category (all the "utilities" together) rather than by what changes together, yielding modules that look tidy but couple tightly in practice. The discipline is to cut along genuine axes of change and ownership, keep interfaces narrow and stable, and redraw a seam when coupling proves it wrong rather than papering over it.

How it implements the components¶

modular_decomposition_plan — its core deliverable: the chosen set of boundaries that separate the system into independently changeable parts.
interface_contract — each module's narrow published interface is the contract through which others depend on it without touching its internals.
coordination_boundary — by confining interaction to interfaces, the module boundary is the coordination boundary, capping what each part must coordinate with.

It does not turn these boundaries into independently deployable running services or plan the migration to get there — that is Service Decomposition's — nor does it define a curated core-vs-extension host, which is Platform Core / Extension Model's specialization of the same seam-drawing idea.

Instantiates: Scalable Architecture Design — supplies the foundational decomposition-and-interface limb the capacity mechanisms build on.
Sibling mechanisms: Service Decomposition · Platform Core / Extension Model · Distributed Service Model · Horizontal Scale-Out · Partitioning or Sharding · Resource Pooling · Vertical Scale-Up · Cloud Scaling Pattern · Franchise-like Replication · Standardized Rollout Template · Scalable Governance Cadence

Notes¶

Modular Architecture is a design principle; Service Decomposition is what happens when you apply it to a running system and split it into deployable services, and Distributed Service Model is the runtime once those services live on the network. The three share the language of interfaces but sit at different points on the same path — principle, transformation, runtime.

References¶

[1] Conway's Law: a system's design tends to reflect the communication structure of the organization that produced it. It bounds where modular seams can actually hold — boundaries that cut across team lines are continually eroded by the coordination the org keeps needing. ↩