Clean Architecture adds interfaces, DTOs, and mapping code at every ring boundary. What concrete trade-offs does that indirection buy you, and in what kind of project would a senior engineer recommend against applying the full four-ring structure?

## What the indirection buys: testability Every ring boundary in Clean Architecture - use case to gateway, controller to use case, use case to presenter - is crossed through an interface that the inner ring owns, and that indirection is what makes use cases **unit-testable in isolation**: a `PlaceOrderUseCaseTest` can inject an in-memory fake implementing `OrderRepository` and a fake `PaymentGateway`, run the interactor's actual validation and orchestration logic, and assert on the output data, all in milliseconds, with zero database, zero HTTP server, and zero framework context to boot. This is a genuine, measurable benefit: teams that adopt this structure typically see unit test suites for business logic run in seconds rather than minutes, because nothing touches infrastructure. ## The second benefit: technology-swap cost The second, less frequently realized, benefit is technology-swap cost. Because the use case only knows about an interface it declared, replacing the concrete implementation is, in principle, a matter of writing a new adapter class and rewiring dependency injection, without touching a single use case: - moving from a hand-rolled JDBC repository to a JPA one; - or from Postgres to DynamoDB; - or from a REST controller to a gRPC one. In practice this benefit is realized less often than the testability one, because most services only ever get one production database and one production delivery mechanism over their entire lifetime; the 'we might swap the database' premium is frequently paid up front and never collected. ## The cost is combinatorial The cost is combinatorial: for N use cases each touching M external dependencies, you're maintaining roughly N interfaces plus N-or-more implementations plus DTOs/mapping code at each boundary, on top of the actual business logic. A field added to an order - say, a new `giftMessage` string - has to be threaded through the input DTO, the use case, possibly the entity, the output DTO, and the presenter/view model, where a simpler layered approach might have required touching one or two of those. This slows down the single most common kind of change in a young or fast-moving product (adding/adjusting a field or a simple rule) in exchange for protecting against a kind of change (swapping the whole persistence or delivery technology) that may never happen. ## The 'pass-through' failure mode The most common production failure mode is the 'pass-through' use case: an interactor class whose `execute()` method does nothing but call `repository.save(mapper.toEntity(input))` and immediately return, with zero actual business logic - no validation, no orchestration, no rule. When most of the use cases in a codebase look like this, the architecture is paying its full indirection cost (extra files, extra layers to navigate, extra onboarding) while collecting essentially none of its benefit, because there's no meaningful logic being protected or tested in isolation; a straightforward CRUD/transaction-script approach would have delivered the same behavior with a fraction of the files. ## Where a senior engineer pushes back A senior engineer should push back on adopting the full four-ring structure for: 1. a short-lived internal tool or admin panel with a two-week expected lifespan; 2. an early-stage prototype whose primary job is validating whether the product should exist at all, where the schema and rules are expected to change wildly week to week; 3. or a small service with one obvious, unlikely-to-change persistence technology and a single client, where the realistic risk being hedged against (a framework/database swap) is vanishingly small relative to the team's velocity needs. In these cases, a simpler layered architecture, or even a transaction-script style with light separation between HTTP handling and a service class, ships faster, onboards faster, and doesn't leave a trail of one-line pass-through interactors nobody trusts to represent real business logic. ## The middle ground This tension shows up concretely in teams that adopt Clean Architecture wholesale for a startup MVP: three months in, half the use cases are one-line pass-throughs, every schema change requires touching five files instead of one, and the team quietly starts collapsing layers back together for anything that isn't core domain logic - which is itself a legitimate, senior move: applying the full ring structure selectively, to the handful of use cases with genuine business rules (pricing, eligibility, workflow state machines), while letting simple CRUD endpoints skip straight from controller to repository, gets most of the benefit at a fraction of the cost.