Modular Design Systems

Complex engineered systems are organized into hierarchies whose elements interact strongly within groups and weakly across them. Simon (1962) described this near-decomposable structure as a recurring architecture of complexity: the reason large systems are tractable at all is that most interaction stays local to a subsystem, and only a thin traffic of interaction crosses between them.

Decomposition is what turns that observation into a design move. Cutting a system into parts can support parallel work, focused verification, replaceability, maintenance, reuse, change isolation, and fault containment (Parnas, 1972; National Aeronautics and Space Administration [NASA], 2016). None of those outcomes is automatic. Each depends on the criterion used to divide the system and on the quality of the interfaces that result. A module, in this sense, is a bounded part of a system with a coherent responsibility and a defined interface to the rest of the system (Parnas, 1972) — not simply a smaller piece of code or hardware.

These qualities pull against one another. A boundary drawn to maximise reuse tends to need a more general interface; a specialised module can be faster or simpler but harder to replace. Choosing where to cut is therefore a judgement about which of these properties the system most needs.

A change is the most practical test of an architecture: when one decision has to change, how far do its consequences have to travel? Two properties predict the answer. Cohesion describes how strongly a module’s internal elements belong together around a single focused responsibility. Coupling describes the dependency between modules — what one must know about, receive from, or coordinate with another (Parnas, 1972).

High cohesion and low coupling are the same idea seen from two sides. When related decisions live together and unrelated ones live apart, a change tends to stay inside one boundary. When internal data is shared, call-order assumptions are hidden, and dependencies run in every direction, a single local change reaches several owners at once.

The failure mode is change propagation. When editing a payment provider forces edits in checkout, email, analytics, and inventory, the symptom is not badly written lines — it is a decision that should have stayed local leaking across boundaries.

An interface is the complete agreement two elements need in order to interact — not merely the connector drawn between them on a diagram. It defines what crosses the boundary and the conditions under which the exchange is expected to work (NASA, 2016).

This is why two components can fit physically, or connect technically, and still be incompatible. If their timing, their meaning for a shared value, their allowable states, their versions, or their assumptions about errors differ, the connector carries data the other side cannot correctly use. A complete interface names all of it.

A strong boundary does two things at once: it reveals what another module needs in order to use it safely, and it conceals the design decisions that module should not depend on. Information hiding assigns the decisions most likely to change to individual modules and keeps them behind stable interfaces (Parnas, 1972). When a hidden decision later changes, the change stops at the boundary.

Two mechanisms support information hiding and are often confused with it. Encapsulation is a means of enforcing a boundary; abstraction is a simplified view of something for a particular purpose. Both serve information hiding, but neither is a synonym for it (Parnas, 1972).

The same reasoning appears wherever systems are built, though the constraints differ by domain. A replaceable battery pack has to meet mechanical, electrical, thermal, and safety limits at its interface. A software service exposes operations and data contracts while owning its internal storage decisions. A manufacturing cell groups equipment and work around a production responsibility. A team boundary assigns decision ownership but also creates a coordination interface. And a reusable UI component packages a set of visual and behavioural decisions (NASA, 2016; Parnas, 1972).

Software gives the most familiar examples. JavaScript modules use explicit export and import statements to declare exactly what a module makes available and what it consumes; browser modules get their own scope, run in strict mode, and execute once per module graph (Mozilla Developer Network, 2026). Atomic Design organises interface work as atoms, molecules, organisms, templates, and pages — a useful design-system methodology for composition and consistency, but a component hierarchy, not a complete system architecture or a universal decomposition method (Frost, 2016; International Organization for Standardization, 2022).

Event mediation is a structural choice inside this space. In direct communication a sender calls receivers it knows by name. With an event bus, a sender publishes an event contract and subscribers react without the sender naming them. That removes some direct dependencies and can isolate a change to one subscriber — but it introduces new operational contracts of its own: delivery, ordering, ownership, observability, and schema evolution all become things someone has to design and govern.

Every boundary that isolates change also adds an interface that has to be designed, integrated, governed, tested, and evolved. Modularity is therefore a trade study, not a score to maximise (Parnas, 1972; Simon, 1962).

Take a worked case: a smart-home security service that must detect conditions locally, apply rules, notify people, and stay useful during an internet outage. A useful decomposition works through three moves.

A useful design does not maximise the number of modules. It protects the decisions most likely to change, supports the operating model the system actually needs, and keeps the cost of each interface proportionate to the benefit it buys. When a team splits one workflow into thirty tiny services and then spends most of its time coordinating releases, the fragmentation cost has overwhelmed the isolation benefit.