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
-
@Entitymaps anOrderEntityto anorderstable. -
JpaRepository<OrderEntity, String>gives CRUD for free. - 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
Top comments (0)