| name | module-layering |
| status | beta |
| description | Know and enforce your module dependency graph — derive inter-module edges from the canonical dependency signal, catch circular dependencies, and enforce intended layering with tooling. Use when a codebase has many modules or packages and layering is a real concern. |
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
Reach for this when a codebase has enough modules or packages that dependency relationships are non-trivial — multiple packages, a plugin ecosystem, or a layered architecture where the direction of dependencies matters. A single small module does not need a graph.
Workflow
- Confirm the concern — enough modules that layering matters; if not, skip.
- Identify the canonical dependency signal and derive the edges.
- State the intended layering explicitly, per layer.
- Enforce with tooling in the check gate; treat a circular dependency or an edge against the intended direction as a failure.
- Keep the graph as a documented artifact, updated with the code.
Completion criteria
- Edges are derived from the canonical dependency signal, not ad hoc inspection.
- Intended layering is explicit; circular dependencies are surfaced.
- Layering is enforced by tooling in the check gate, so violations fail.
- The graph is a documented artifact and the single home for dependency facts.
