Comparison
Dependency rulevsLayered architecture
Dependency rule
an import from the domain package to the database package failed the build, and the arrow only ever points inward.
Clean architecture's single load-bearing constraint: source dependencies point only toward higher-level policy, never outward toward detail. Everything else in the diagram — the circles, the names of the layers — follows from it, and enforcing it with an automated check is worth more than any amount of documentation. Where control has to flow outward, dependency inversion is what turns the arrow around.
Full entry →Layered architecture
the controller called the database directly and three people commented on the pull request.
Arranging code so that each layer may only call the one beneath it — typically interface, application, domain, infrastructure. It gives you a rule that can be checked rather than an aesthetic, which is why layering violations are one of the few design arguments a linter can settle. Layers stop paying when they become pass-through: four layers that each rename a field are ceremony, not structure.
Full entry →