Application Layering

Service layers, repositories and the transport/application/domain/infrastructure split — including when each is genuine structure and when it is ceremony that adds indirection without behaviour.

The Service Layer

A use case expressed as a plain function that knows nothing about HTTP — which is what lets a job, a CLI and an endpoint share it.

Q · Where does business logic go once more than one caller needs it?
The Repository Layer

A named place for the queries your domain asks, so the definition of "active subscription" lives once instead of in eleven call sites.

Q · What does a repository buy you that calling the ORM directly does not?
When the Repository Is Just Indirection

A repository whose methods are one-line passthroughs to the ORM adds a file, a name and a hop, and removes no decision from anyone.

Q · When does wrapping the ORM cost more than it buys?
Transport, Application, Domain, Infrastructure

Four layers, one rule that matters — dependencies point inward — and a scale at which the whole thing is overhead.

Q · What are the layers of a backend service, and which rule about them is load-bearing?
Alternatives to Layering

Vertical slices, transaction scripts and hexagonal are not lesser versions of layering — they optimise for different changes, and one of them probably matches yours.

Q · If layered architecture is not the only option, what are the real alternatives and what does each optimise for?
Fat Controllers

The 300-line handler is a real production problem for a specific reason: it puts a payment call inside a database transaction and nobody can see it.

Q · What actually goes wrong when the handler does everything, beyond it being hard to read?
Dependency Management Without the Container

Passing a dependency in instead of importing it is the whole idea; a container is one way to do the wiring and is not the idea.

Q · How should code get hold of the things it depends on, and who decides which implementation it gets?