agentleFS
rrezartprebrezarrezartprebreza/spring-boot-skills/skills/spring-boot-4/layered-architecture/SKILL.md

layered-architecture

Skill344 starsChanged 3 months agoMITView on GitHub

Use when generating or modifying any Spring Boot class — controllers, services, repositories, DTOs, mappers, or configuration. Enforces strict layer separation and prevents business logic from leaking across boundaries.

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Never returns @Entity classes directly — always map to response DTOs

    line 26
  2. Very specific:

    Never injects @Repository — always goes through a @Service

    line 27
  3. Distinctive:

    No business logic — pure data access

    line 85
  4. Distinctive:

    Use records for immutable DTOs (Java 16+)

    line 91
  5. Distinctive:

    Keep mapping logic out of controllers and services — use dedicated mapper classes or static factory methods

    line 105
  6. Very specific:

    Use @ConfigurationProperties for type-safe config — never raw @Value for groups of related settings

    line 140

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Layered Architecture

Layer Rules

@RestController        ← HTTP only. No business logic. No JPA entities in responses.
      ↓ DTOs
@Service               ← All business logic lives here. Orchestrates repositories.
      ↓ Domain objects / Entities
@Repository            ← Data access only. No business logic. Returns entities or projections.
      ↓ JPA / JDBC
Database

Controller Layer

  • Handles HTTP: parsing requests, validating input (@Valid), returning responses
  • Calls ONE service method per endpoint — no orchestration in controllers
  • Never returns @Entity classes directly — always map to response DTOs
  • Never injects @Repository — always goes through a @Service
  • Exception handling via @ControllerAdvice, never try/catch in controllers
// ✅ GOOD
@PostMapping("/orders")
public ResponseEntity<OrderResponse> createOrder(@Valid @RequestBody CreateOrderRequest request) {
    Order order = orderService.createOrder(request);
    return ResponseEntity.status(HttpStatus.CREATED).body(OrderResponse.from(order));
}

// ❌ BAD — business logic in controller
@PostMapping("/orders")
public ResponseEntity<Order> createOrder(@RequestBody CreateOrderRequest request) {
    if (request.getItems().isEmpty()) throw new RuntimeException("No items");
    Order order = orderRepository.save(new Order(request)); // direct repo access
    return ResponseEntity.ok(order); // returning entity
}

Service Layer

  • Contains all business logic, validation rules, and orchestration
  • @Transactional lives here, not in controllers or repositories
  • Constructor injection only — never @Autowired field injection
  • One service per aggregate root (OrderService, not OrderAndPaymentService)
  • Returns domain objects or DTOs — never HttpServletRequest / HttpServletResponse
  • Retries and concurrency caps on service methods via Framework 7's @Retryable / @ConcurrencyLimit (enable with @EnableResilientMethods) — no spring-retry dependency
// ✅ GOOD
@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepository;
    private final InventoryService inventoryService;

    @Transactional
    public Order createOrder(CreateOrderRequest request) {
        inventoryService.reserve(request.items()); // records use accessor names, not getX()
        Order order = Order.from(request);
        return orderRepository.save(order);
    }
}

// ❌ BAD — field injection, HTTP concern in service
@Service
public class OrderService {
    @Autowired private OrderRepository orderRepository;

    public ResponseEntity<Order> createOrder(...) { ... } // HTTP type in service
}

Repository Layer

  • Extends JpaRepository<Entity, ID> or CrudRepository
  • Custom queries via @Query or query derivation — no raw SQL unless unavoidable
  • Returns entities or Spring Data Projections — never raw Object[]
  • No business logic — pure data access

DTOs

  • Separate Request / Response DTOs — never use the same class for both
  • Validation annotations (@NotNull, @Size, etc.) on Request DTOs only
  • Static factory method ResponseDto.from(Entity entity) for mapping
  • Use records for immutable DTOs (Java 16+)
// ✅ GOOD
public record OrderResponse(UUID id, String status, List<LineItemResponse> items, Instant createdAt) {
    public static OrderResponse from(Order order) {
        return new OrderResponse(order.getId(), order.getStatus().name(),
            order.getItems().stream().map(LineItemResponse::from).toList(),
            order.getCreatedAt());
    }
}

Mapper Pattern

  • Keep mapping logic out of controllers and services — use dedicated mapper classes or static factory methods
  • Mapper is a plain class or utility — not a Spring bean unless it needs injected dependencies
  • Entity → Response DTO: static method on the response DTO (OrderResponse.from(order))
  • Request DTO → Entity: static factory on the entity (Order.from(request)) or a mapper class
  • Collection mapping: use .stream().map(OrderResponse::from).toList() — never manual loops
// ✅ GOOD — dedicated mapper for complex mappings
public class OrderMapper {

    public static OrderResponse toResponse(Order order) {
        return new OrderResponse(
            order.getId(),
            order.getStatus().name(),
            order.getItems().stream().map(OrderMapper::toLineItem).toList(),
            order.getCreatedAt()
        );
    }

    public static Order toEntity(CreateOrderRequest request, User user) {
        Order order = Order.create(request.customerEmail(), user);
        request.items().forEach(item ->
            order.addItem(item.productId(), item.quantity()));
        return order;
    }

    private static LineItemResponse toLineItem(OrderItem item) {
        return new LineItemResponse(item.getProductId(), item.getQuantity(), item.getPrice());
    }
}

Configuration Layer

  • @Configuration classes live in a config/ package — never in service/ or controller/
  • Configuration never imports service or controller classes
  • Use @ConfigurationProperties for type-safe config — never raw @Value for groups of related settings
  • Bean definitions for infrastructure concerns only (RestClient, JsonMapper, SecurityFilterChain)

Cross-Cutting Concerns

  • Logging: use @Slf4j — never System.out.println
  • Validation: @Valid on controller parameters, custom validators as @Component
  • Exception handling: single @RestControllerAdvice class, never try/catch in controllers
  • Auditing: @CreatedDate / @LastModifiedDate with @EnableJpaAuditing

Gotchas

  • Agent tends to put @Transactional on controllers — move it to services
  • Agent uses @Autowired field injection — always use constructor injection (@RequiredArgsConstructor)
  • Agent returns List<Entity> from controllers — always map to List<ResponseDto>
  • Agent creates OrderAndInventoryService god classes — split by aggregate
  • Agent puts mapping logic inside controllers — extract to mapper class or DTO factory method
  • Agent creates @Configuration classes that depend on @Service beans — configuration should only wire infrastructure
  • Agent defines an ObjectMapper bean to customize JSON — Boot 4 uses Jackson 3 (tools.jackson): define JsonMapper beans, and @JsonComponent is now @JacksonComponent
  • Agent adds spring-retry for service-level retries — built into Framework 7 (@Retryable, @EnableResilientMethods)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.