The Layer Map

Shared core

The chapter below remains the canonical explanation for both goals. Keep its model, examples, and trade-offs shared; only the deliberate practice changes with the route.

Learn deeply: build evidence

Use this chapter’s TaskFlow work to make one small, observable change. Run the stated acceptance checks before recording practice.

Prepare for interviews: explain the trade-off

Without notes, explain the boundary this chapter protects, one concrete implementation decision, and the cost of a tempting shortcut. Then answer one follow-up using the chapter’s own example.

Section 1The line a request walks

Every request to a Spring backend does the same trip: it enters at the top, is handed down one layer at a time, reaches the database, and the answer is handed back up the same steps in reverse. Read this diagram top-to-bottom, then bottom-to-top.

Section 2The four kinds of class

That is the entire cast. Memorise this table; it is the Rosetta Stone for reading any Spring file. When you open an unfamiliar class, your first question is always "which row is this?"

Section 3How the pieces get connected — IoC & DI, concretely

You now have four kinds of class. But who creates them, and how does the Controller get hold of the Service? This is the part that mystifies everyone, and it is genuinely two ideas wearing scary names.

The two name tags do the two jobs. @Service (and its siblings) says "Spring, please build one of these and keep it in the box." A constructor says "and to build me, you'll need to hand me these."

@RestController               // tag: "I'm a controller — build me, and route HTTP to me"
public class TaskController {

    private final TaskService service;   // I depend on the chef

    // Spring sees this constructor and injects a TaskService bean automatically.
    public TaskController(TaskService service) {
        this.service = service;          // DI just happened — no `new` anywhere
    }
}

Section 4Where every buzzword lives on the map

This is the de-tangler. Every intimidating word you listed is pinned to one seam of the same line. Read the "sits at" column and the fog lifts.

Section 5"MySQL or Mongo or Java's own DB?" — untangled

This one deserves its own section because it trips everyone. The key insight: the database is behind a seam. Your Service asks the Repository to "save this task" and does not care what is on the other side. Swapping databases is mostly a change to application.properties, not to your classes.

Section 6Where the files physically live

Layers are also folders (Java calls them packages). The convention is one package per kind. When you open a real project, this is what you'll see — and now you can predict every folder's job:

Section 7A method: read any Spring class in ten seconds

You said you can read Spring code now but not crystal clear. Here is a repeatable routine to make it crisp. Run these four questions, in order, on any class you open:

1. Which kind is it? Look at the class annotation. @RestController, @Service, @Repository/JpaRepository, or @Entity → you now know its one job and where it sits on the line.
2. What does it depend on? Look at the constructor (or @Autowired fields). Those are the layers below it that Spring will inject. That's the class's outgoing arrows.
3. What does it expose? For a Controller, the @GetMapping/@PostMapping methods are its public URLs. For a Service, its public methods are the rules it offers upward.
4. Where does the data stop? Follow the calls down until you hit the Repository — that's the floor, where it meets the database. Everything above is just handing the parcel along.