Spring Data: repositories, aggregates and fetch plans
Prerequisites: 01-ecosystem
Where does repository abstraction stop?
Goal & mental model verified
Spring Data builds repository abstractions around store-specific behavior. JPA has persistence-context and relationship semantics; Data JDBC uses a simpler aggregate model. Derived queries reduce boilerplate without replacing query design.
[S27] [S28]Worked example · design exercise synthesis
A broker dashboard pages quotes by tenant and status. Use a response projection and a deliberate fetch plan instead of traversing every policy relationship during JSON serialization.
[S27] [S28] [S29]Engineering decision synthesis
Choose JPA when its entity model helps; choose JDBC-style access when explicit aggregate operations fit. R2DBC is a non-blocking access model, not reactive JPA.
[S27] [S28] [S29]Pitfall & diagnosis synthesis
A compact repository method can still produce expensive SQL. N+1 access and loading oversized graphs should be diagnosed through executed queries and row counts, not annotation counts.
[S27] [S28] [S29]Improve & validate synthesis
Capture SQL and query plans for representative tenant sizes. Validate pagination and fetch plans together; compare query count and end-to-end latency after changes.
[S27] [S28] [S29]Check yourself: Is R2DBC just JPA returning Mono?
No. It is a different non-blocking relational access model.