What this prompt does
This prompt asks the AI to design and tune JPA entities for a [domain] system built around your [entities], since most Spring Boot performance problems trace back to fetch strategy and N+1 queries. For each entity it defines fields with proper column types and constraints, maps relationships with correct cascade types, chooses LAZY versus EAGER fetch with justification, adds @EntityGraph definitions for common access, builds Spring Data repositories with custom queries for [query_patterns], implements the specification pattern for dynamic filtering, adds audit fields, configures a second-level cache via [cache_provider] for [cached_entities], writes queries that avoid N+1, and includes Flyway migration SQL — explaining the performance implication of each choice.
The structure works because fetch strategy and caching are decisions that quietly determine performance, and this prompt forces them to be reasoned through up front with tradeoffs spelled out. Tying entity graphs and queries to your real [query_patterns] keeps the design grounded in how the data is actually read. The specification pattern is worth calling out too: it lets dynamic filters compose from optional criteria, which avoids the slow accumulation of nearly-identical repository methods that domains like this tend to grow over time.
When to use it
- You are modeling a non-trivial JPA domain and want fetch strategies decided deliberately, not by default.
- Existing endpoints suffer N+1 queries and you need entity graphs or fetch joins to fix them.
- You want a second-level cache on read-heavy, rarely-updated entities without caching volatile data.
- You need dynamic filtering and want the specification pattern instead of a proliferation of query methods.
- You want the performance tradeoff of each mapping choice explained, not just the code.
- You need consistent audit fields across entities via
@CreatedDateand@LastModifiedDate.
Example output
Expect annotated JPA entity classes with relationship mappings and fetch strategies, @EntityGraph definitions, Spring Data repositories with custom JPQL or Criteria queries for [query_patterns], specification classes for filtering, second-level cache configuration for [cached_entities], and Flyway migrations. Each significant design choice comes with a short note on its performance implication rather than bare code.
Pro tips
- List
[entities]with their relationships so cascade types and ownership of the foreign key are mapped correctly. - Default relationships to LAZY and let the AI justify any EAGER choice; accidental EAGER fetching is a frequent source of slow queries.
- Make
[query_patterns]specific (products by category with reviews, order history with items) so the entity graphs target real access paths. - Cache only genuinely read-heavy, rarely-updated
[cached_entities]; caching volatile data via[cache_provider]causes stale reads. - Use
@EntityGraphor fetch joins for the N+1 hotspots rather than flipping a relationship to EAGER globally. - Iterate by pasting a slow query's SQL log and asking which mapping or graph change would eliminate the extra round trips.
