Dependency Constraint Check¶
Design-time procedure — instantiates Relation Constraint Enforcement
A design-time procedure that tests an artifact's dependency edges against architectural rules — no cycles, no forbidden cross-boundary or lower-tier edges — and prescribes fixes for edges that already violate them.
A Dependency Constraint Check evaluates the depends-on edges of an artifact — a codebase, a release plan, a supply chain — against a set of architectural rules, and prescribes a correction wherever an edge already breaks them. Its defining move is that it governs dependency relationships by pattern: no cycles, dependencies may point only "downward" across declared layers or trust tiers, and required prerequisites must be present. Unlike a runtime gate it is a point-in-time analysis that produces a verdict, and unlike a pure conformance test it carries a remediation for edges that leaked in through legacy code or expedient shortcuts — telling you not just that a dependency is illegal but how to unwind it.
Example¶
A platform team enforces a strict layering — ui → application → domain, never upward — and a rule that production services may depend only on stable-tier packages, never on anything marked deprecated or experimental. Before a release, the Dependency Constraint Check builds the module import graph and tests every edge. It finds two violations: domain imports something in ui (a back-edge that both reverses the sanctioned direction and threatens a cycle), and a payments service pulls in a deprecated crypto library. For the back-edge, the check's remediation prescribes introducing an interface in domain and inverting the dependency so ui depends on the abstraction, not the reverse. For the deprecated library, it prescribes migrating to the supported replacement and flags the edge as inherited-from-legacy so it is tracked down rather than silently grandfathered.
The structural rot is named and given a fix plan while it is still a diff, before it hardens into the kind of tangle that no one dares touch. The rule it leans on is the acyclic dependencies principle.[n1]
How it works¶
- Build the dependency graph. Extract the depends-on edges of the artifact, to the chosen transitive depth.
- Test each edge against the pattern rules. Check allowed-tier and boundary compatibility (may this layer/tier depend on that one?) and direction/acyclicity (does any edge point back or close a cycle?).
- Classify existing violations. Separate newly introduced edges from ones inherited via legacy or migration.
- Prescribe remediation. For each violation, recommend a concrete correction — invert via an interface, vendor, replace, or quarantine — and emit a verdict a downstream gate can act on.
Tuning parameters¶
- Rule set — which boundaries, tiers, and cycles are forbidden. Stricter rules catch more rot and block more legitimate exceptions.
- Scope — direct dependencies only versus the full transitive closure. Transitive is thorough but noisier and slower.
- Legacy stance — grandfather existing violations or block them all. Grandfathering unblocks today at the risk of normalizing the debt forever.
- Remediation aggressiveness — advise a fix versus attempt an automated refactor. Automation scales but can mangle non-trivial cases.
- Transitive depth — how many hops out the check follows before it stops.
When it helps, and when it misleads¶
Its strength is catching structural decay — cycles, upward dependencies, banned libraries — before it hardens, and turning "you have forty violations" into an ordered fix plan rather than a wall of red. It makes the shape of the dependency graph a governed thing rather than an accident of who imported what.
Its failure mode is that it only sees the dependencies it can observe: dynamic, reflective, or runtime-injected edges are invisible to a static pass, so a clean report can hide real coupling. Grandfathering legacy violations to keep the build green tends to make "temporary" exceptions permanent, and a rule set too strict blocks a genuinely justified edge and pushes teams toward hidden workarounds. The guarding discipline is to track the legacy-violation count downward over time, keep the boundary rules owned and current, and set a firm expiry on any grandfathered edge.
How it implements the components¶
This procedure fills the dependency-pattern slice of the archetype:
compatibility_rule— encodes which dependency pairings are permitted by layer, trust tier, or lifecycle state, and flags forbidden ones.directionality_rule— enforces that depends-on edges point the sanctioned way and never close a cycle.remediation_path— prescribes the concrete correction (invert, replace, vendor, quarantine) for violating edges already present.
It does not persist an audit_trail of each access decision — that is Authorization Relationship Check — nor keep a scheduled monitoring_signal over the whole estate, which is Relational Integrity Test Suite; this is a point-in-time analysis, not a standing log or monitor.
Related¶
- Instantiates: Relation Constraint Enforcement — it constrains dependency edges to an allowed structure and remediates the ones that violate it.
- Consumes: Policy Relation Rule — supplies the architectural boundary and tier rules the check tests against.
- Sibling mechanisms: Authorization Relationship Check · Foreign-Key Constraint · Graph Schema Validation · Relational Integrity Test Suite · Policy Relation Rule · Workflow Transition Guard · Role Compatibility Check
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Dependency Constraint Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a design-time procedure that tests an artifact's dependency edges against architectural rules — no cycles, no forbidden cross-boundary or lower-tier edges — and prescribes fixes for edges that already violate them.
Independent corroboration: The frozen evidence defines Dependency Constraint Check as 'A design-time procedure that tests an artifact's dependency edges against architectural rules — no cycles, no forbidden cross-boundary or lower-tier edges — and prescribes fixes for edges that already violate them', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Software architecture cohered static checks for cycles, forbidden layer crossings, and other dependency-graph constraints.
Related originating lineages:
- Engineering & Design — Systems architecture supplied cross-boundary dependency rules and remediation of illegal couplings.
Review resolution: Software architecture cohered static checks for cycles, forbidden layer crossings, and other dependency-graph constraints. Engineering dependency constraints are a material parallel lineage to software package and build-graph checks.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The acyclic dependencies principle (Robert C. Martin) — the dependency graph of components should have no cycles, because a cycle binds the components into a unit that cannot be built, tested, or released independently. It is the canonical rule a dependency check enforces on edge direction. ↩