OrderHub Day 1 stored orders in a HashMap — restart the server and they're gone. Day 2 fixes that: real persistence with JPA + PostgreSQL, and thanks to Day 1's layered design, the controller and service don't change a single line.

🗄️ See it (place orders, "restart", watch what survives): https://dev48v.infy.uk/orderhub/day2-jpa-postgres.html

The payoff of a repository port

Day 1 defined an OrderRepository interface with an in-memory implementation. Day 2 adds a second implementation backed by JPA — and swaps it in. Same interface, new guts. The service depends on the port, so it never noticed.

JPA in three pieces

1. @Entity maps an OrderEntity to an orders table.
2. JpaRepository<OrderEntity, String> gives CRUD for free.
3. A small adapter implements the existing port, mapping entity ↔ domain so the domain stays framework-free.

H2 locally, Postgres in prod

Local dev runs on in-memory H2 (zero setup). Production reads SPRING_DATASOURCE_URL / USERNAME / PASSWORD from the environment and talks to PostgreSQL. Same jar, different database — that's Spring config doing its job.

🔨 Full step-by-step (entity → repo → adapter → datasource config) on the page: https://dev48v.infy.uk/orderhub/day2-jpa-postgres.html

OrderHub — a production-grade Spring Boot backend, one feature a day.
🌐 https://dev48v.infy.uk · Code: https://github.com/dev48v/order-hub-from-zero