Modular Boundaries

Drawing the lines between parts of a system, in code and in the organization, so that each part hides its internals behind a simple interface and can be understood and changed on its own. The same principle governs a module's boundary and a team's boundary.

Composed Of

• Deep Modules — make each part offer a lot behind a small interface.
• Information Hiding — keep each design decision inside one part, not spread across several.
• Fracture Planes — choose where to split along real seams (domain, change cadence, risk).
• Team API — give each team an explicit interface, so people-level boundaries are as legible as code-level ones.
• Hierarchy — at systems scale, decompose so most interactions stay within a subsystem and few cross between them.
• Orthogonality — keep the parts independent so a change in one does not ripple into the others.
• Coupling and Cohesion — the underlying measures a boundary optimizes: high cohesion within, low coupling across.
• Connascence — a finer metric for the kind and strength of coupling a boundary should keep weak and local.
• Bounded Context — the boundary of a domain model and its language; the strategic, domain-meaning version of a modular boundary, where the seam follows where terms change meaning.

Why it Matters

Boundaries are where complexity either gets contained or leaks. A well-placed boundary lets one team or one module change without rippling outward; a badly placed one forces constant cross-boundary coordination. The insight that unites the sources is that code boundaries and team boundaries are the same problem (see Conway's Law).

Signals

• A change stays within one module and one team.
• Interfaces are small and stable while implementations grow.
• Failure signal: routine changes require edits across several parts or coordination across several teams.

Risks

Over-splitting into many shallow parts, each adding an interface and cognitive load. Boundaries drawn along technical layers or org convenience rather than real seams.