A team building a strictly layered application (presentation -> business -> data access, where each layer may call only the layer below it) keeps merging pull requests that quietly violate the rule - e.g., a controller class importing a repository class directly. Code review alone isn't catching these. What mechanisms can enforce a layered architecture's dependency-direction rule automatically, and what exactly do they check?

## Why code review misses these Code review fails to reliably catch layer-boundary violations for a structural reason, not because reviewers are careless: - a single illegal import buried in a 200-line diff is easy to miss; - reviewers often don't have the entire dependency graph of the codebase memorized well enough to spot an indirect violation (class A in the data layer doesn't import a presentation class directly, but imports class B which does); - and under deadline pressure, 'this one import is probably fine' judgment calls get waved through. Review is a human, situational check; a dependency-direction rule needs a check that runs the same way, every time, regardless of who's reviewing or how rushed the PR is. ## The standard mechanism — automated architecture tests The standard mechanism for this is **automated architecture testing**, which encodes the layering rule as an executable check that runs in the normal test suite and fails the build on violation. - On the JVM, **`ArchUnit`** is the widely used tool: it's a library added as a test dependency, letting you write rules like 'no classes residing in a data package should depend on classes residing in a presentation package,' or the inverse allow-list version. `ArchUnit` inspects the actual compiled classfiles (via reflection over the classpath) to check every reference, not just the source text, so it catches violations however they're expressed in code. - Equivalent tools exist per ecosystem — **`NetArchTest`** for .NET, **`dependency-cruiser`** for JavaScript/TypeScript, which parses the module import graph against a rules config and can also generate a visual dependency graph. All of these share the property that matters: they run in CI on every PR exactly like any other test, so a violation is caught within minutes of being introduced, not discovered months later during a manual architecture audit. ## The stronger version — separate build modules A stronger version of the same idea moves enforcement from a test that could theoretically be skipped to the build system itself: splitting the codebase into genuinely separate build modules per layer — in a Gradle multi-module project, a presentation module, a business module, and a data module, where the data module's build file declares no dependency on presentation at all. In that setup, an illegal import isn't a failing test, it's a **compile error**, because the class simply isn't on the classpath of the module trying to reference it — there's no way to accidentally slip past it, because it's not a rule being checked, it's a structural fact about what code exists to be imported at all. ## Migration cost versus guarantee strength The trade-off between these two mechanisms is migration cost versus guarantee strength. - **Adding an ArchUnit-style test** to an existing, already-layered-by-convention codebase is comparatively cheap: write the rule, run it against the current codebase, fix whatever it flags, and it's live. - **Restructuring into genuinely separate build modules** is a much bigger undertaking for an existing large system — it usually means untangling accidental cross-layer references that current package-level organization was silently allowing, reorganizing build files, and potentially dealing with slower or more complex build graphs — but it produces a guarantee that can't be silenced by deleting or skipping a test. ## Failure modes that persist Even with these mechanisms in place, failure modes persist. - **Architecture-test rules degrade over time** if exceptions accumulate faster than they're revisited — a rule that started as a clean allow-list gains enough carve-outs over successive deadline-driven PRs that it stops meaningfully testing anything. - **Tests can also simply be disabled** ('disable this for now, we'll fix it later') under release pressure, and if nothing tracks disabled tests, 'later' doesn't arrive. - **And static dependency-graph checks**, whether test-based or module-based, can miss violations introduced through indirection that doesn't show up as a static import — reflection-based access, a dependency-injection container wiring a presentation-layer bean into something the data layer resolves dynamically, or a shared mutable singleton that both layers reach through a common utility class. ## Where this shows up in practice Real-world adoption of this pattern is common in large, multi-team Java codebases specifically because they're the systems most prone to slow architectural erosion across many contributors over years; teams building on Spring Boot frequently add `ArchUnit` test suites (sometimes alongside Spring Modulith's own module-boundary verification, which builds on similar dependency-analysis techniques) specifically to keep a layered or modular structure honest as the team and codebase grow well past the size where any one person can hold the whole dependency graph in their head.