Comparison
Clean architecturevsDependency rule
Clean architecture
entities, then use cases, then adapters, then frameworks — and nothing in an inner circle names anything outside it.
Martin's synthesis of hexagonal, onion and several older layered schemes into concentric circles governed by the dependency rule. Its distinctive contributions are the naming of use case interactors as a layer of their own and the insistence that frameworks are a detail at the outermost ring. In practice it and hexagonal architecture describe the same system, and arguing about which one a codebase follows is rarely a productive hour.
Full entry →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 →