Module Layering

A discipline for knowing and enforcing the dependency graph of a multi-module or multi-package codebase. It keeps the intended layering explicit, surfaces circular dependencies, and makes a violation fail instead of silently drifting.

The defining constraint: derive the graph from the canonical dependency signal — the single authoritative statement of what each module depends on (a package manifest's peer dependencies, a module's declared imports) — rather than from ad hoc inspection. Enforce intended direction with tooling, not memory.

Know the graph

• Identify the canonical dependency signal for each module: the declared peer/regular dependency for packages, or the module imports for in-repo modules.
• Derive the inter-module edges from that signal, grouped by the package or module hierarchy, so the graph is reproducible rather than hand-maintained.
• Keep the graph as a documented artifact (a module-graph page or generated report) so it is the single home for dependency facts.

Enforce layering

• Decide the intended layering — which modules may depend on which. State it explicitly (a layering rule per layer), not implicitly.
• Detect circular dependencies — a cycle means no clear layer boundary and is a signal to re-examine ownership.
• Enforce with tooling (e.g. a dependency-cruiser or graph analyzer), running in the check gate so a new edge that violates the intended direction fails rather than silently drifting.

When it applies