Layers: route handler, service, repository

Where does business logic belong — the route handler, a service, or the repository?

The service. A route handler translates HTTP into a call — parse, validate the shape, map the result to a status code — and should be readable in one screen with nothing worth unit-testing in it. A repository translates between the domain and the database and knows no rules. The service is the only layer that knows what the business means, which is why it is the only one whose tests survive swapping the web framework or the database.

The tell that the split has gone wrong: a transaction spanning two repository calls with a rule between them, sitting in a controller. That rule belongs one layer down.

Is that not just extra indirection for a small app?

Often, yes — and the honest answer is that the layers earn their keep at the point a second caller appears. The moment the same operation has to run from an HTTP route, a background job and a CLI command, logic living in the handler is either duplicated or reached for through the web framework. Until then, one file with a clear function is fine, and pretending otherwise is architecture as decoration.