Dependency Rule
The constraint that source-code dependencies may point only inward, from detail toward policy, regardless of the direction of control flow.
The single rule that clean, onion and hexagonal architectures share. Concentric layers — entities and domain at the centre, use cases around them, then interface adapters, then frameworks and drivers at the edge — and dependencies point only inward.
The domain therefore knows nothing of the database, the web framework, the message broker or the UI. Those are details, and details depend on policy.
The point that causes confusion: control flow and dependency direction are different things. An HTTP request flows inward and the response flows outward, while a use case that must write to a database calls an interface it owns, implemented at the edge. Control goes outward; the dependency still points inward.
What it buys, concretely: business rules testable with no infrastructure; frameworks replaceable without touching the domain; and the domain expressed in domain terms rather than in the vocabulary of whichever ORM was current.
What it costs: mapping between layers, more files, and indirection that is genuinely unhelpful in a small CRUD service where the domain is thin. The value scales with the amount of business logic — a service that mostly validates and stores gains little; one with substantial rules gains a great deal.
Enforce it mechanically with a dependency check in CI, or it erodes in months.