Leif P. HeaneyAI/ML & Systems Engineer
Schedule Meeting

Field guide 01 / Lesson 02

Modular Design Systems

Decompose systems around responsibility, hidden decisions, and explicit interface contracts.

48 minutes10 sections10 questionsUpdated
On this page
  1. 1. Why decompose systems?
  2. 2. What makes a useful module?
  3. 3. Cohesion, coupling, and change propagation
  4. 4. Interfaces and contracts
  5. 5. Information hiding and abstraction
  6. 6. Modularity across domains
  7. 7. Software modules and Atomic Design
  8. 8. Event-bus simulator
  9. 9. Modularity tradeoffs
  10. 10. Worked architecture exercise
  11. Worked example
  12. Misconceptions
  13. Glossary
  14. Knowledge check
  15. References

Your destination

Learning objectives

  • Explain why engineers decompose systems.
  • Define a module in context.
  • Distinguish purposeful decomposition from arbitrary subdivision.
  • Explain cohesion, coupling, and information hiding.
  • Describe interfaces as behavioral and operational contracts.
  • Identify tight coupling and change propagation.
  • Compare physical, software, organizational, and interface modularity.
  • Evaluate modularity tradeoffs.
  • Propose a modular decomposition for a familiar system.

Before you begin

  • Systems Thinking is recommended but not required.

1. Why decompose systems?

Decomposition creates manageable reasoning units, but the cut lines determine what becomes easy or difficult to change.

Complex engineered systems are often organized into hierarchies whose elements interact strongly within groups and more weakly across groups. Simon described this near-decomposable structure as a recurring architecture of complexity. (Simon, 1962)

A useful decomposition can support parallel work, focused verification, replaceability, maintenance, reuse, change isolation, and fault containment. Those outcomes are not automatic: they depend on the criterion used to divide the system and on the quality of the resulting interfaces. (Parnas, 1972; National Aeronautics and Space Administration, 2016)

2. What makes a useful module?

A module is valuable when it creates a meaningful boundary around responsibility and change.

  • Clear responsibility: a reason for the elements to belong together.
  • Internal cohesion: related work and decisions remain close.
  • Limited external dependency: other modules need little internal knowledge.
  • Stable interface: externally visible commitments change less often than implementation.
  • Replaceability: an alternative can satisfy the same contract.
  • Testability: behavior can be examined at the boundary.
(Parnas, 1972)

These qualities pull against one another. A boundary that maximizes reuse may require a more general interface; a specialized module may be faster or simpler but less replaceable.

3. Cohesion, coupling, and change propagation

A change is a practical test of architecture: how far must its consequences travel?

Tangled

  • Shared internal data
  • Hidden call-order assumptions
  • Many direct dependencies
  • A local change reaches several owners

Well bounded

  • Owned internal state
  • Explicit contract
  • Few necessary dependencies
  • Most changes stop at the boundary
(Parnas, 1972)

Architecture simulator

Direct dependencies or event mediation?

PublisherOrder service
InterfaceDirect API calls
Ready. Choose a mode, toggle modules, and broadcast an event.

Change impact: the sender knows three receivers.

Text alternative and tradeoff

Direct calls make receivers explicit but couple the sender to each receiver. Event mediation lets the sender depend on one event contract, while subscribers depend on delivery, ordering, schema, and observability behavior. A mismatched contract can isolate one subscriber when validation is local, or create a wider cascade when the shared contract changes incompatibly.

4. Interfaces and contracts

An interface is the complete agreement needed for two elements to interact—not merely the connector drawn between them.

  • Inputs and outputs, including units and data formats.
  • Physical fit, power, capacity, and environmental limits where relevant.
  • Behavior, sequence, state, and timing.
  • Communication protocol and error handling.
  • Assumptions, ownership, security, and version compatibility.
(National Aeronautics and Space Administration, 2016)

Two components can fit physically or connect technically and still be incompatible because their timing, meaning, allowable state, version, or error assumptions differ.

5. Information hiding and abstraction

A strong boundary reveals what another module needs and conceals design decisions it should not depend on.

Information hiding

  • Conceals replaceable implementation decisions.
  • Reduces dependency on internal representation.
  • Still exposes behavior needed for safe use.

Not the same as

  • Secrecy from authorized stakeholders.
  • Withholding hazards or constraints.
  • An excuse for undocumented behavior.
(Parnas, 1972)

Encapsulation is a mechanism for enforcing a boundary; abstraction is a simplified view for a purpose. They support information hiding but are not interchangeable terms. (Parnas, 1972)

6. Modularity across domains

The same reasoning appears in physical, software, organizational, and interface design, but the constraints differ.

  • Physical: a replaceable battery pack must meet mechanical, electrical, thermal, and safety constraints.
  • Software: a service module exposes operations and data contracts while owning internal storage decisions.
  • Manufacturing: a cell groups equipment and work around a production responsibility.
  • Organization: a team boundary assigns decision ownership but also creates coordination interfaces.
  • User interface: reusable components organize visual and behavioral decisions.
(National Aeronautics and Space Administration, 2016; Parnas, 1972)

7. Software modules and Atomic Design

Software and interface design provide familiar applications of broader modular principles.

JavaScript modules use explicit export and import syntax to define what a module makes available and what it consumes. Browser modules have their own scope, run in strict mode, and execute once per module graph. (Mozilla Developer Network contributors, 2026)

Atomic Design organizes interface work as atoms, molecules, organisms, templates, and pages. It is a design-system methodology: it can improve composition and consistency, but it is not a complete system architecture or a universal decomposition method. (Frost, 2016)

Broader engineering concept

  • Module: contextual system boundary
  • System architecture: elements, relationships, and principles
  • Interface: cross-boundary contract

Specific applications

  • JavaScript module: language/runtime unit
  • Design system: reusable UI decisions and components
  • Atomic Design: component hierarchy methodology
(International Organization for Standardization, 2022; Mozilla Developer Network contributors, 2026; Frost, 2016)

8. Event-bus simulator

Event mediation changes who knows whom. It removes some direct dependencies while introducing new operational contracts.

In direct communication, a sender calls known receivers. With an event bus, a sender publishes an event contract and subscribers react without the sender naming them. This can isolate some changes, but it can also make ordering, delivery, ownership, observability, and schema evolution harder.

9. Modularity tradeoffs

Every boundary adds an interface that must be designed, integrated, governed, tested, and evolved.

  • Interface overhead and translation cost.
  • Performance or latency across boundaries.
  • Integration and version compatibility.
  • Excessive fragmentation and distributed ownership.
  • Difficulty selecting stable boundaries early.
  • Reuse pressure that conflicts with specialized optimization.
  • Operational complexity created by independent deployment.
(Parnas, 1972; Simon, 1962)

Modularity is therefore a trade study, not a score to maximize. A useful design protects likely change, supports the needed operating model, and keeps interaction cost proportionate to the benefit.

10. Worked architecture exercise

Decompose a smart-home security service around responsibilities and contracts.

  1. Name system outcomes: detect, decide, notify, and allow authorized control.
  2. Group responsibilities: sensors, local decision logic, identity and access, notification, user experience, and audit history.
  3. Identify likely change: sensor vendors, notification channels, policy rules, and storage technology.
  4. Hide those decisions behind interfaces.
  5. Specify timing, offline behavior, error handling, ownership, and versioning.
  6. Test a change: replace the notification provider and trace affected modules.
(Parnas, 1972; National Aeronautics and Space Administration, 2016)

Put it together

Decompose a smart-home security service

The system must detect conditions locally, apply rules, notify people, and remain useful during an internet outage. (Parnas, 1972; National Aeronautics and Space Administration, 2016)

  1. Separate sensing from policy evaluation so device details do not leak into rules.
  2. Define an event contract with type, source, timestamp, confidence, and schema version.
  3. Keep identity and authorization separate from presentation.
  4. Specify local fallback behavior at the interface, not as an undocumented implementation detail.
  5. Trace replacement of one notification provider to verify change isolation.
  6. Record tradeoffs: more boundaries improve replaceability but increase integration and observability needs.
Reflect: Which design decision is most likely to change, and which module should hide it?

Check the mental model

Common misconceptions

Myth: Decomposition is just cutting a system into smaller pieces.

The criterion for the cut determines whether responsibilities and change are isolated. (Parnas, 1972)

Myth: Low coupling means modules never interact.

Useful modules interact through deliberate, bounded dependencies.

Myth: Information hiding means secrecy.

It hides replaceable design decisions while preserving necessary safety and operating information. (Parnas, 1972)

Myth: Event-driven architecture is always more modular.

It trades direct dependency for event-contract, delivery, ordering, and observability concerns.

Myth: More reusable pieces always improve the design.

Over-generalization and fragmentation can increase coordination and reduce fitness for purpose.

Remember this

Lesson summary

  • Decomposition is a design decision.
  • High cohesion keeps related responsibility together; low coupling limits necessary dependency.
  • Information hiding protects likely-to-change decisions.
  • Interfaces include behavior, timing, assumptions, error handling, ownership, and versioning.
  • Event mediation changes dependency shape but introduces its own contracts.
  • Choose modularity based on change, integration, performance, verification, and ownership tradeoffs.

Key language

Glossary

Architecture
The fundamental concepts or properties of an entity in its environment, expressed through its elements, relationships, and principles of design and evolution. (International Organization for Standardization, 2022)
Module
A bounded part of a system with a coherent responsibility and a defined interface to the rest of the system. (Parnas, 1972)
Cohesion
The degree to which the responsibilities and elements inside a module belong together around a focused purpose. (Parnas, 1972)
Coupling
The degree of dependency between modules or systems, including what one must know about or receive from another to operate. (Parnas, 1972)
Information hiding
A decomposition principle that assigns likely-to-change design decisions to modules whose interfaces conceal those decisions from other modules. (Parnas, 1972)
Interface
A defined boundary across which elements interact or exchange matter, energy, data, or control, including the assumptions and rules governing that exchange. (National Aeronautics and Space Administration, 2016)
Abstraction
A purposeful simplification that keeps the characteristics needed for a question while leaving out detail that is not needed. (SEBoK, 2026)

Apply what you learned

Knowledge check

Answer all 10 questions, then submit for explanations and a score. You can retry as often as you like.

Question 1What most strongly determines whether a decomposition is useful?
Question 2Low coupling means modules should have no dependencies.
Question 3Changing a payment provider requires edits in checkout, email, analytics, and inventory code. What does this most directly suggest?
Question 4Which belong in an interface contract?
Question 5What does information hiding protect?
Question 6Which structure best isolates a change in one subscriber?
Question 7Which statement correctly distinguishes Atomic Design?
Question 8A team splits one workflow into 30 tiny services and now spends most of its time coordinating releases. Which tradeoff is visible?
Question 9Order a practical decomposition exercise.
Question 10When is a specialized non-reusable module reasonable?

Evidence

References

References are formatted to the project’s APA 7 conventions from structured source data.

  1. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. Association for Computing Machinery. https://doi.org/10.1145/361598.361623
  2. Simon, H. A. (1962). The architecture of complexity. Proceedings of the American Philosophical Society, 106(6), 467–482. https://www.sfipress.org/21-simon-1962
  3. Frost, B. (2016). Atomic design. Brad Frost Web. https://atomicdesign.bradfrost.com/
  4. Mozilla Developer Network contributors. (2026). JavaScript modules. MDN Web Docs. Mozilla. Retrieved July 16, 2026, from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
  5. National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (Rev. 2). (NASA/SP-2016-6105 Rev2). National Aeronautics and Space Administration. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  6. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2022). Software, systems and enterprise — Architecture description. (ISO/IEC/IEEE 42010:2022). International Organization for Standardization. https://www.iso.org/standard/74393.html

Save your place

Finished this lesson?

Progress stays on this device. No account or tracking service is required.