The Layers of Clean Architecture

Robert Martin's Clean Architecture draws the same Dependency Rule as four concentric layers, and it adds one concept hexagonal leaves implicit: the use case (or interactor) as an explicit object representing a single application operation. Where hexagonal emphasizes the boundary (ports and adapters), Clean emphasizes what lives in each ring - and especially that thin layer of application-specific logic between the domain and the edge.

The four rings

From the center out:

• Entities (innermost) - enterprise-wide business objects and rules. Your DDD entities, value objects, and aggregates live here. They'd be true even if this particular app didn't exist. Depend on nothing.
• Use Cases - application-specific business rules. Each use case orchestrates entities to accomplish one operation ("transfer money," "post transaction"). Depend only on entities.
• Interface Adapters - translators: controllers, presenters, repository implementations that convert between the use-case world and the outside. Depend inward on use cases.
• Frameworks & Drivers (outermost) - Spring, JPA, the database, the web server. Glue and configuration. The volatile edge.

The rule is unchanged: nothing in an inner ring knows about an outer ring. An entity never imports a use case; a use case never imports a controller or Spring.

The use-case interactor

The concept worth internalizing is the use case as an object. Instead of business logic smeared across fat controllers and services, each application operation is one focused class with one method:

// The use case: one operation, orchestrating entities via ports
class TransferMoneyUseCase implements TransferMoney {          // driving port (inbound)
    private final AccountRepository accounts;                  // driven port (outbound)
    private final TransactionPublisher events;

    public TransferResult transfer(AccountId fromId, AccountId toId, Money amount) {
        Account from = accounts.findById(fromId).orElseThrow();
        Account to   = accounts.findById(toId).orElseThrow();
        from.withdraw(amount);                                 // entities enforce their invariants
        to.deposit(amount);
        accounts.save(from); accounts.save(to);
        events.publish(new MoneyTransferred(fromId, toId, amount));
        return TransferResult.success();
    }
}

Notice what it is and isn't. It is the application's business rules: the sequence of steps to transfer money, coordinating entities and ports. It isn't HTTP (no @RequestMapping, no JSON), isn't SQL (it uses the AccountRepository port), and isn't presentation. Reading it tells you exactly what the operation does, free of technical noise. This is where hexagonal's "driving port" gets a body.

Entities vs. use cases

A subtle but important split: entity logic is rules that are true regardless of the application ("an account can't go negative"); use-case logic is application-specific orchestration ("to transfer, load both accounts, move the money, publish an event"). The invariant lives on the Account entity; the workflow lives in the TransferMoneyUseCase. Keeping them separate means the entity is reusable across use cases, and the use case reads as a clear script.