Clean Architecture draws four concentric rings - Entities, Use Cases, Interface Adapters, and Frameworks & Drivers. For a typical web application, what kind of code lives in each of these four rings, and how does data get from an outer ring's format into a form the innermost ring can use?

## Entities: the innermost ring Entities are the innermost ring in Clean Architecture and hold the enterprise-wide business rules and critical data structures - the objects and invariants that would still make sense even if this particular application didn't exist, because they encode truths about the business domain itself. - An `Order` entity enforcing 'total must equal the sum of line items' or an `Account` entity enforcing 'balance cannot go negative without an overdraft flag' belongs here. - Entities have no knowledge of use cases, HTTP, databases, or UI; they are typically the most stable code in the system because they change only when the fundamental business rules change, not when technology choices change. ## Use Cases: application-specific orchestration One ring out sit Use Cases (Interactors), which encode application-specific business rules - the orchestration steps needed to accomplish one particular thing a user or system does, such as 'place an order' or 'cancel a subscription.' A use case pulls in one or more entities, applies whatever validation and sequencing the specific operation requires, and talks to the outside world exclusively through interfaces it declares itself: - an **output boundary** (sometimes literally an `OutputBoundary` interface or a presenter callback); - any **gateway interfaces** it needs, like `OrderRepository` or `PaymentGateway`. Critically, use cases never import a concrete database class, a concrete HTTP framework class, or a concrete UI class - only interfaces they own. ## Interface Adapters: translation in both directions The Interface Adapters ring is where the translation happens in both directions. - **Going in.** A Controller takes a framework-specific input - an HTTP request, a CLI argument array, a gRPC message - and converts it into a plain input data structure the use case's `execute()` method understands, containing nothing but primitive/simple types, never framework classes. - **Going the other way.** When a use case finishes, it hands a plain output data structure to its output boundary, and a Presenter (also in this ring) converts that into a view model shaped for whatever the delivery mechanism needs - a JSON DTO for a REST API, a printable string for a CLI, a `ViewModel` object for a UI template. This ring also holds Gateway implementations - the concrete class that implements `OrderRepository` using JPA, for instance - even though the gateway's interface was declared one ring further in. ## Why the translation code gets its own ring The reason for splitting Interface Adapters into its own ring, distinct from both Use Cases and Frameworks/Drivers, is to give the translation code somewhere to live that is neither pure business logic nor raw framework machinery. Without this ring, teams end up doing input parsing and JSON marshalling directly inside use-case methods (polluting business logic with HTTP concerns) or, worse, letting entities themselves grow Jackson annotations and getters/setters shaped for a particular API response (polluting the domain model with a specific client's needs). Concentrating conversion logic in Controllers/Presenters/Gateways means a change to the wire format - renaming a JSON field for a specific mobile client - touches only the Presenter, never the use case or entity. ## The cost, and where it goes wrong The cost of this many rings is real: a single 'place order' flow can require an input DTO, an output DTO, a use-case interface, a use-case implementation, a controller, a presenter, and a gateway implementation - seven-plus files for one operation, legitimately heavy for a small app. 1. The most common failure mode in production codebases is skipping the translation and passing Entities straight out of a controller as the HTTP response body; it looks harmless until the entity gains a method or a lazy-loaded JPA relationship that then gets serialized straight to a client, causing either an accidental data leak or a `LazyInitializationException` in production. 2. A second common failure is a 'fat' presenter or controller that starts making its own business decisions (e.g., deciding whether a discount applies) because it's easier than adding a parameter to the use case - quietly moving business logic into a ring that isn't supposed to hold it. ## One request, end to end Concretely, in an order-processing service: an HTTP POST /orders hits `OrderController`, which builds a `PlaceOrderInputData(customerId, items)` and calls `PlaceOrderUseCase.execute(input)`. That use case loads/validates the `Order` entity, calls the `PaymentGateway` interface it owns, and on success builds a `PlaceOrderOutputData(orderId, status)` which it hands to an `OrderPresenter`. The presenter converts that into `OrderResponseJson(id, status, links)` that Spring serializes back to the client. Not one of those inner classes imports Spring, JSON, or JPA - only the Controller, Presenter, and the Gateway implementation know those exist.