The common convention is Controller (handles HTTP concerns — request mapping, validation, response shaping) → Service (business logic, transaction boundaries) → Repository (data access) → Entity/Domain (persistence-mapped or core domain objects), with each layer only depending on the layer directly below it, and controllers never talking to repositories directly. This keeps concerns separated and each layer independently testable.

Beginner3 min

TCSInfosysWiproCapgeminiAccenture

#Layered Architecture

Skipping a Layer Is a Common Early-Career Architecture Smell

A controller calling a repository directly, bypassing the service layer, might look like a harmless shortcut for a simple endpoint — but it means transaction boundaries (usually declared at the service layer) and business rules have nowhere consistent to live, and as that endpoint inevitably grows more complex, the logic ends up scattered inconsistently across whichever layer happened to have direct repository access at the time.

Controller (HTTP) → Service (business logic, @Transactional) → Repository (data access) → Entity — each layer depends only on the one below