Code Architecture
Layered, Clean and Hexagonal: dependency direction, domain isolation, and when the abstraction stops paying for itself.
Presentation → Application → Domain → Infrastructure, with dependencies pointing one way only — a cheap, widely understood way to keep HTTP out of business rules and SQL out of controllers, until the layers become pass-through ceremony that adds files without adding decisions.
Model–View–Controller and its descendants split "what the data and rules are" from "how it is shown" from "how input becomes a change" — the pattern every web framework ships with, and the one most often reduced to a folder layout while the rules quietly move into the controller.
Concentric rings — Entities, Use Cases, Interface Adapters, Frameworks & Drivers — governed by one rule, source-code dependencies point inward, so business rules never import the web framework or the database; powerful where boundaries matter, and pure overhead in a system too small to have boundaries.
The application core exposes ports — interfaces it needs and interfaces it offers — and every external thing (REST, a database, a queue, a payment provider) is an adapter plugged into a port, so the domain is isolated from technology and any adapter can be swapped for an in-memory one in a test.