Study Notes
Spring Boot learning pathcore-concepts

Core concepts retrieval review

An attempt-first review of layers, persistence, API boundaries, transactions, security, and tests.

25 min read·verified Spring Boot 4.x·reviewed 2026-08-29

Assumes you know

After this you should be able to

  • Explain a layered request path
  • Predict persistence and transaction behavior
  • Defend an API boundary decision
RetrievalCore conceptsSpring Boot

Back to Spring roadmap

Core concepts · retrieval review

Retrieve decisions, predict consequences, and debug the seams before reading the answer structures.

Learning goal

Attempt first#

  1. A controller directly calls JpaRepository and calculates a discount. What becomes harder to test, reuse, and change? Sketch the corrected dependency direction.
  2. Predict what changes when a managed entity is mutated inside a transaction but no explicit save appears. Which assumption would you verify rather than state as a rule?
  3. A client should never choose a task owner, but your request DTO contains ownerId. Diagnose the boundary leak and state where the owner should come from.
  4. A service creates a project, then fails while adding the first task. Place the transaction boundary and explain the visible result if it is missing.
  5. Choose between a unit test with a mock and a web slice test for a validation failure. What is each test proving?
  6. A logged-in user receives 403 for a private route. Predict the difference between “not authenticated” and “authenticated but not authorized,” then name the evidence you would inspect.

Completion evidence#

Draw one request from controller to database and back, marking its DTO boundary and transaction. Then explain your drawing to another person or record a two-minute answer.

Current status: Not started

Open answer structures after your attempt

Use a stable chain: controller translates HTTP; service owns use-case rules and transaction decisions; repository owns persistence access. A DTO makes the API contract intentional, while identity should come from authenticated context. Explain test choice by the boundary under test, not by which annotation is fashionable. For security failures, separate credentials from granted authority before changing code.