Retrospektive & der Weg nach vorn
Reflektiere die Entscheidungen, die BookVault geprägt haben, die Abwägungen dahinter und wohin es als Nächstes geht - im weiteren Spring-Ökosystem und in deiner Laufbahn.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
You've built BookVault from an empty project to a secured, tested, observable, containerized service. This final lesson steps back: why is it shaped the way it is, what did each decision trade off, and where do you go from here? Understanding the reasoning is what turns a finished project into transferable judgment.
The decisions that shaped BookVault
Every layer involved a choice. The valuable thing isn't the choice itself but knowing when it's right:
- A modular monolith, not microservices. BookVault is one deployable with clean internal boundaries. This traded away independent scaling and deployment for radical simplicity - the right trade until real pressure (team size, differing scale) justifies a split. The boundaries were drawn anyway, so a split stays cheap.
- Records for DTOs, classes for entities. Immutable value carriers versus managed, identity-bearing state - each tool matched to the job, rather than one style forced everywhere.
- Flyway over auto-DDL. Explicit, versioned, reviewable migrations traded a little upfront effort for a database whose shape is never a surprise.
- Blocking code with virtual threads, not reactive. BookVault kept simple, debuggable imperative code and got high concurrency from Java 21 - reserving reactive's complexity for problems that actually need it.
- Events over direct calls. A small amount of indirection bought decoupling and a ready seam for a future service split.
Judgment is knowing what NOT to build
Notice how much BookVault doesn't do: no premature microservices, no reactive rewrite, no native image by default. Senior engineering is largely restraint - reaching for complexity only when a real need justifies it. 'Start simple, add a layer when it earns its keep' is the through-line of the whole path, and the most valuable thing to carry forward.
Where BookVault would grow next
Real systems keep evolving. Honest next steps for BookVault:
- Split a service when one part needs independent scaling - the documented architecture shows how.
- Add caching (Spring Cache) for hot, read-heavy catalog queries.
- Richer domain: reservations, fines, due-date reminders (a scheduled job), search.
- Native image if you deploy serverless and cold-start matters.
- CI/CD: automate the test-build-deploy pipeline you now understand by hand.
The wider Spring ecosystem
The path covered the core, but Spring is vast. With your foundation, these are approachable:
- Spring Batch — robust large-scale batch processing.
- Spring Integration — enterprise integration patterns.
- Spring GraphQL — a GraphQL API alongside (or instead of) REST.
- Spring Authorization Server — run your own OAuth2/OIDC provider.
- Spring Cloud — the full distributed-systems toolkit you met in the microservices module.
- Spring AI — bring LLMs into your apps with the familiar model.
Each is 'more of the same Spring': starters, auto-configuration, injectable beans, portable abstractions. You already know how to learn them.
BookVault was a recipe, but along the way you learned techniques - dependency injection, transactions, the request lifecycle, the test pyramid, externalized config. Techniques transfer: a cook who understands heat and seasoning can make dishes they've never seen. You can now approach a Spring project you've never met and know how to reason about it - that's the real outcome, not the one app.
Keep building, and share it
The fastest way to deepen this is to build your own project end to end - your ideas, your domain - and put it on GitHub. Contribute to open source, write about what you learn, help someone a step behind. Teaching and building in public compound faster than any course.
Imagine a reviewer asks: 'Why didn't you build BookVault as microservices from the start, and why blocking code instead of reactive?' Give a clear, senior answer for each - the trade-off you made and the condition under which you'd choose differently.
What is the central engineering principle running through BookVault's design?
Key takeaways
- Each of BookVault's layers reflects a deliberate trade-off; the transferable skill is knowing when each choice is right.
- It favors a modular monolith, records vs classes by role, Flyway migrations, blocking code with virtual threads, and events over direct calls.
- Senior judgment is largely restraint: adopt complexity (a service split, reactive, native) only when a concrete need justifies it.
- BookVault would grow by splitting a service under real pressure, adding caching, a richer domain, native images, or CI/CD - each a deliberate next step.
- The wider Spring ecosystem (Batch, Integration, GraphQL, Authorization Server, Cloud, AI) is approachable because it's 'more of the same Spring'.
- You learned transferable techniques, not one recipe - keep building your own projects and sharing them.