后端核心

David-Li04062026-10-25查看 1963复制 1172

使用 Java/Spring Boot 设计和实现后端 API、服务、JPA 实体以及安全性。适用于 API 设计、控制器/服务实现、数据库建模和安全模式。

Download (.md)

📘如何使用这个技能

  1. 1
    复制技能内容·点击上方「Copy SKILL.md」复制全部内容,或 Download 下载到本地
  2. 2
    打开你的 AI 客户端·支持 Claude Code、Trae、Cursor、ChatGPT、DeepSeek、Kimi 等任意 AI 助手
  3. 3
    粘贴为系统提示/知识文件·Claude Code:放入 .claude/skills/ 目录;普通对话:作为首条消息发送并说「请严格按这份技能文档执行」
  4. 4
    直接提出你的需求·AI 会按技能定义的工作流、格式和约束来处理,无需再解释背景

💡 提示:技能生效后,每次对话只需一句需求,AI 会按 SKILL.md 的流程执行。

SKILL.md4793 chars
---
name: backend-core
description: Design and implement backend APIs, services, JPA entities, and security with Java/Spring Boot. Use for API design, controller/service implementation, database modeling, and security patterns.
---

# Backend Core Skill

## When to Use

- Creating or modifying REST API endpoints
- Designing DTOs, entities, or database schema
- Implementing service layer business logic
- Adding security (OTP, rate limiting, audit logging)
- Working with files under `backend/`

---

## CRITICAL: Security Requirements

### OTP Step-up Authentication (MANDATORY)

**Gated Actions:**
- **Redeem** (사용하기): MUST verify OTP session before creating RedeemSession
- (Optional) Profile edit, account recovery

**Implementation:**
- Service layer checks: `OtpSession.isValid()` before critical action
- Session TTL: ~10 min
- Return 403 with `"OTP_REQUIRED"` error code if not verified

**Anti-patterns:**
- NEVER trust client-side "otpVerified" flag
- ALWAYS validate backend-side session

### Rate Limiting & Brute-force Protection
- Phone + name lookup is brute-force risky → add rate limits & cooldown
- Owner-only endpoints must be protected
- Terminal shares owner session in MVP (OK), but log all actions

### Audit Logging
Log issuance/redeem/migration events with:
- walletId, storeId, stampCardId, timestamp, result

---

## Stack

**Default:**
- Java 17
- Spring Boot 3.x
- Spring Web
- Validation (Bean Validation)
- Spring Data JPA
- MySQL

**Optional (only if needed):**
- Spring Security
- Redis (TTL / rate limiting)
- Testcontainers

---

## Architecture

### Package Strategy (Feature-based)

```
com.project.kkookk
  global/
    config/
    security/
    exception/
    response/
    util/
  owner/
    controller/
    service/
    repository/
    domain/
  store/
    controller/
    service/
    repository/
    domain/
  stampcard/
    controller/
    service/
    repository/
    domain/
  wallet/
    controller/
    service/
    repository/
    domain/
  issuance/
    controller/
    service/
    repository/
    domain/
  redeem/
    controller/
    service/
    repository/
    domain/
  migration/
    controller/
    service/
    repository/
    domain/
  qrcode/
    controller/
    service/
    exception/
```

### Layer Responsibilities
- **Controller:** HTTP + DTO mapping + validation
- **Service:** use case orchestration + transactions
- **Domain:** entities, value objects, domain logic (invariants, rules)
- **Repository:** persistence & queries

Keep controllers thin. Put orchestration in services, business rules in domain.

---

## Code Style

**Base:** Google Java Style, with these overrides:
- Indentation: 4 spaces
- Max line length: 120

### Naming Conventions
- Use camelCase for variables/methods/classes
- Avoid unclear names: `Data`, `Info`, `Item`, `Util`, `Common`
- Avoid abbreviations if possible

**Boolean naming:**
- Local boolean variables: prefix with `is...` (e.g., `boolean isValid`)
- Entity boolean fields: **no** `is` prefix (Lombok getter issue). Example: `private boolean active;`

**Find vs Get:**
- `find*`: may not exist → return Optional / empty list
- `get*`: must exist → throw exception when missing

### Lombok Allowed
- `@Getter`, `@Builder`, `@RequiredArgsConstructor`, `@Slf4j`
- JPA Entity: `@NoArgsConstructor(access = PROTECTED)`

### Imports
- No wildcard imports
- Avoid static imports in production (tests can use assert static imports)

### Braces
Never omit braces (`{}`), even for single-line if.

### Complexity Guardrails
- Keep nesting depth around 2
- Prefer early returns and method extraction

---

## API Design (Required Output Format)

Before implementing an API, always output this structure:

### 1) Endpoints
- method + path
- auth
- status codes

### 2) Request/Response DTOs

### 3) DB Model
- tables + main columns
- indexes (only if needed)

### 4) Validation & Exceptions

### 5) Implementation Steps
- Controller → Service → Repository

### 6) Test Cases
- success
- failure

### 7) API Design Checklist (MVP)
- Swagger/OpenAPI disabled (MVP)
- API contracts documented (DTO + status codes + error format)

### MVP Constraints
- Prefer polling over websockets
- Keep TTL & idempotency explicit in spec

---

## Persistence (JPA)

### General
- Use JPA entities for aggregates
- Use `@Transactional` on service layer
- Read-only queries: `@Transactional(readOnly = true)`

### Index Hint
- Index wallet/store IDs for fast lookups

### Idempotency
- Prefer unique constraints (e.g., one active session per reward) to enforce one-time completion

---

## PR Checklist

- [ ] DTO validation exists
- [ ] Error response consistent
- [ ] Transaction boundaries correct
- [ ] Idempotency / TTL considered where needed
- [ ] Tests added (success + failure)
- [ ] No secrets in config
来源:skillsdirectory

评论0

登录后参与评论

还没有评论,来抢沙发吧