Scaffold a Spring Boot feature

This skill covers the basic entity/repository/service/controller shape assuming JPA over a relational database. For MySQL/PostgreSQL-specific ID generation, dialects, or JSON columns once past this basic shape, see spring-boot-jpa. If the feature's data is document-shaped rather than relational, use spring-boot-mongodb's modeling guidance in place of step 1–2 below instead. For where the new feature's files should physically live (a new top-level feature package vs. dropping classes into existing layer packages), see spring-boot-architecture's "Package structure" section — the order below assumes the feature gets its own package.

Generation order

Build in this order — each layer depends on the one before it:

1. Entity — @Entity, @Table, @Id with @GeneratedValue, relationships default to fetch = FetchType.LAZY, prefer Set over List for collections where duplicates aren't meaningful.
2. Repository — extend JpaRepository<Entity, IdType>. Add derived query methods or @Query with JOIN FETCH for anything that will load a collection — don't let a default findAll()-shaped method return entities with lazy collections un-fetched (that's the N+1 setup; see spring-boot-review). On Spring Boot 4.x, @ConfigurationProperties classes must use private fields or a record — public-field binding was removed; a record is the preferred style for new code (see the BillingProperties example below).
3. Service — constructor-injected repository dependencies, @Transactional on methods that span more than one repository call, business rules live here.
4. Controller — thin, delegates to the service, maps DTOs at the boundary.
5. DTOs — Java records, validated with Jakarta Bean Validation annotations.

Pattern