The Capstone Project
What you'll build and why: BookVault's architecture end to end, how the companion repo is your reference, and how to work through it.
On this page
You've learned the container, the web, data, security, testing, events, microservices thinking, and production concerns - each with BookVault growing a layer alongside it. This capstone pulls it all together: you'll build BookVault end to end, from an empty project to a deployable service, and understand not just how each piece works but why it's there and how they fit.
What you're building
BookVault is a community-library API. Members browse a catalog and borrow books; librarians manage the catalog. It's small enough to hold in your head, yet it exercises every layer of a real Spring service:
HTTP request
│
┌───────▼────────┐ Security: JWT auth, MEMBER vs LIBRARIAN roles
│ Controllers │ Web: @RestController, DTOs, validation, ProblemDetail
└───────┬────────┘
┌───────▼────────┐ The container wires these together (dependency injection)
│ Services │ Business logic, @Transactional, publishes domain events
└───────┬────────┘
┌───────▼────────┐ Data: JPA entities, Spring Data repositories, Flyway
│ Repositories │
└───────┬────────┘
┌─────▼─────┐
│ Database │
└───────────┘
Cross-cutting: tests (unit → slice → integration), observability
(Actuator/metrics), virtual threads, and a container image for deploy.The build order
You'll build inside-out, the way the path taught it - each layer resting on the ones before:
- Scaffold & domain — a Spring Boot project and the Book/Member/Loan model, wired by the container.
- Web & data — expose it over REST, then make it durable with JPA and Flyway.
- Security — JWT login, BCrypt, and role-based access.
- Testing — the pyramid: unit, slice, integration.
- Events & production — a domain event on borrow, then observability, virtual threads, and Docker.
- Retrospective — the decisions and trade-offs, and where to go next.
How to use the companion repository
The BookVault companion repo (linked from this path) is your reference solution. Its git history mirrors this journey - each module is a commit that adds exactly one layer - so you can:
- Build alongside it: write each layer yourself, then compare with the repo's version.
- Read it as a worked example: walk the commits to see how the codebase grew.
- Run it:
./mvnw spring-boot:run, then exercise the API with thecurlcommands in its README.
Build it, don't just read it
The single biggest thing that turns 'I understand Spring' into 'I can build with Spring' is typing the code yourself. Aim to write each layer before looking at the reference. When you get stuck, the repo and the earlier module lessons are there - but struggle a little first; that's where the learning is.
This capstone synthesizes - it assumes the modules
Each lesson here compresses a whole module into its role in the finished service. If a step feels thin, that's your cue to revisit that module's lessons - the depth is there. The capstone's job is to show how the pieces connect, not to re-teach each one.
Before building, trace it in your head: a POST /api/loans arrives with a JWT to borrow a book. Name,
in order, the layers it passes through and one responsibility each has - from authentication to the
database write and the event that follows.
What is the guiding approach of this capstone?
Key takeaways
- BookVault is a small but complete Spring service that exercises every layer: web, data, security, testing, events, and production concerns.
- You build inside-out - domain and container first, then web/data, security, testing, and finally events and production.
- The companion repo is a reference solution whose commit history mirrors the build order, one layer per commit.
- The most valuable habit is writing each layer yourself before comparing with the reference.
- This module synthesizes the path; thin steps are cues to revisit the module that covered them in depth.