The Dependency Rule: the core never knows about the outside

Origin and goal

In 2012, Robert Martin published a blog post titled "The Clean Architecture", noticing that several architectures that appeared independently - Cockburn's hexagonal architecture, Jeffrey Palermo's Onion Architecture, DCI - all converge toward the same goals.

Those goals: a system testable without a UI, without a database, without a web server; a database and a framework that stay details, replaceable without touching business rules; business rules that ignore the outside world entirely.

Rather than inventing a new idea, Martin offered a unified representation - four concentric circles - and a name for the rule that ties them together: the Dependency Rule.

The Dependency Rule

The Dependency Rule states: source code in a circle can only reference elements in the same circle or in a more inner one. Nothing in an inner circle should know the name of a class, function, or variable defined in an outer circle.

This includes data formats. If the inner circle needs data produced by an outer circle, you don't pass a framework structure directly: you define a plain interface, owned by the inner circle, and the outer circle implements it. That's the dependency inversion principle applied to the entire architecture.

The four circles

How does it compare to hexagonal architecture?

Both approaches defend exactly the same idea with different vocabulary. The hexagonal core (domain) maps to Clean Architecture's two inner circles (Entities + Use Cases). Hexagonal ports map to the interfaces that use cases define to talk to the outside.

The real added value of Clean Architecture is naming the "Interface Adapters" layer explicitly as its own thing - whereas hexagonal often leaves it merged with adapters. This intermediate layer (controllers, presenters, mappers) has the sole job of translating formats, carrying no business rule of its own.

In practice, a single project can claim both: "hexagonal architecture organized around Clean Architecture's dependency rule" describes most serious codebases that follow these principles quite well.

Concrete example: the same use case, in explicit layers

Take the "place an order" use case again. In Clean Architecture, you explicitly separate the entity (carrying intrinsic validation rules) from the use case (the interactor, which orchestrates) and from the port it defines for persistence.

// Entity: intrinsic business rule, zero external dependency
class Order private constructor(
    val id: OrderId,
    private val items: List<OrderLine>,
    private val status: OrderStatus,
) {
    companion object {
        fun create(id: OrderId, items: List<OrderLine>): Order {
            if (items.isEmpty()) throw EmptyOrderError()
            return Order(id, items, OrderStatus.Pending)
        }
    }

    fun totalAmount(): Money =
        items.fold(Money.zero()) { sum, line -> sum.add(line.subtotal()) }
}

// Use case: orchestration, defines what it needs through an interface
interface OrderGateway {
    suspend fun save(order: Order)
}

class PlaceOrderInteractor(private val orders: OrderGateway) : PlaceOrder {

    override suspend fun execute(command: PlaceOrderCommand): OrderId {
        val order = Order.create(OrderId.generate(), command.items)
        orders.save(order)
        return order.id
    }
}

Common pitfalls