Conversation
| @@ -0,0 +1,139 @@ | |||
| # API Design Rules | |||
|
|
|||
| ## Controller Structure | |||
There was a problem hiding this comment.
Response Example도 자동화 필요
| | `StringSpec` | Simple validation, utility tests | | ||
|
|
||
| ## Directory Structure | ||
| todo: 아키텍처 변경시 동기화 필요 |
|
|
||
| ### Query Service | ||
|
|
||
| Query Service는 **조회 요청에 대한 데이터 조립** 계층이다. 비즈니스 로직이 아닌, 프레젠테이션을 위한 데이터 조합이 본질이다. |
| @@ -0,0 +1,224 @@ | |||
| #!/bin/bash | |||
| @@ -0,0 +1,224 @@ | |||
| #!/bin/bash | |||
| # | |||
| # DB 스키마를 덤프하여 references/schema.md에 저장하는 스크립트 | |||
There was a problem hiding this comment.
schema.md ignore 처리
soo0711
left a comment
There was a problem hiding this comment.
수고하셨습니당 👍
아래에 의견 추가해뒀습니다!! 확인 부탁드립니다!
| ## Core Principles | ||
|
|
||
| 1. **Rich Domain Model**: Entity owns validation, state changes, and business decisions | ||
| 2. **UseCase = orchestration**: coordinates flow; "how" is decided by Entity |
There was a problem hiding this comment.
usecase 규칙에서 **Orchestration only**: delegates business logic to Entity, calls Repository directly 를 명시해주면서 의미가 중복되는데 Role: Follows Core Principle #2. Allowed to call Repository directly.로 대체할 수 있지 않을까요?
| fun getUser(userId: Long): User = | ||
| userRepository.findByIdOrNull(userId) | ||
| ?: throw UserNotFoundException() | ||
| ``` No newline at end of file |
There was a problem hiding this comment.
여기에 단언을 지양한다는 내용도 추가하면 어떨까요?
| ## Naming Conventions | ||
|
|
||
| | Element | Convention | Example | | ||
| |---------|-----------|---------| | ||
| | Classes | PascalCase | `UserController`, `CreateUserUseCase` | | ||
| | Methods | camelCase | `getUserDetail`, `createUser` | | ||
| | Constants | SCREAMING_SNAKE_CASE | `MAX_PAGE_SIZE` | | ||
| | Packages | lowercase | `com.example.domain.user` | | ||
| | DTOs | Suffix with purpose | `CreateUserRequest`, `UserResponse` | | ||
| | Test Fixtures | `{Entity}TestFixture` | `UserTestFixture` | |
There was a problem hiding this comment.
test-create skill의 레퍼런스에 포함시켜주면 될 것 같아요!
| @@ -0,0 +1,106 @@ | |||
| # Git Conventions Rules | |||
There was a problem hiding this comment.
충돌 해결이나 최신 브랜치 업데이트 시 동기화 전략(Merge vs Rebase)도 명시하면 어떨까요???!
| ## Request DTO | ||
|
|
||
| Located in `application/dto/request/`: | ||
|
|
||
| ```kotlin | ||
| data class CreateUserRequest( | ||
| @field:Schema(description = "User name", example = "John Doe") | ||
| @field:NotBlank | ||
| @field:Size(max = 100) | ||
| val name: String, | ||
|
|
||
| @field:Schema(description = "Email address", example = "john@example.com") | ||
| @field:NotBlank | ||
| @field:Email | ||
| val email: String, | ||
|
|
||
| @field:Schema(description = "Profile settings") | ||
| @field:Valid | ||
| @field:NotNull | ||
| val profile: ProfileRequest | ||
| ) | ||
| ``` | ||
|
|
||
| ### Validation Annotations | ||
|
|
||
| | Annotation | Usage | | ||
| |-----------|-------| | ||
| | `@NotNull` | Field must not be null | | ||
| | `@NotEmpty` | Collection must have elements | | ||
| | `@NotBlank` | String must not be empty/whitespace | | ||
| | `@Size(min, max)` | Length/size constraints | | ||
| | `@Positive` | Number must be > 0 | | ||
| | `@Valid` | Validate nested objects | | ||
|
|
||
| ## Response DTO | ||
|
|
||
| Located in `application/dto/response/`: | ||
|
|
||
| ```kotlin | ||
| data class UserResponse( | ||
| @Schema(description = "User ID", example = "1") | ||
| val id: Long, | ||
|
|
||
| @Schema(description = "User name", example = "John Doe") | ||
| val name: String, | ||
|
|
||
| @Schema(description = "Email address", example = "john@example.com") | ||
| val email: String, | ||
|
|
||
| @Schema(description = "Profile information") | ||
| val profile: ProfileResponse? = null, | ||
|
|
||
| @Schema(description = "Active status", example = "true") | ||
| val isActive: Boolean? = null | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
이부분이 코드 스타일에 있는 부분과 겹치는데 코드스타일에서 data class 사용만 명시하고 여기서만 코드를 명시하는 건 어떨까요?
There was a problem hiding this comment.
data class 사용 여부의 경우는 모델이 인식하기에 code-style 쪽 컨텍스트를 우선 조회할 것 같아서 조금 겹치더라고 양쪽을 유지하는게 어떨까 싶습니다!!
There was a problem hiding this comment.
아 넵!! 모델이 code-style을 우선 조회한다면 중복되더라도 명시적으로 두는 게 안전할 수도 있겠네요!
| name: context-update | ||
| description: Self-feedback skill that analyzes completed work and improves Claude Code context. Use when asked to "update context", "capture learnings", "improve context", or before compaction. Identifies reusable patterns and delegates to appropriate create skills. | ||
| allowed-tools: Read, Write, Edit, Glob, Grep, Bash | ||
| --- |
There was a problem hiding this comment.
새로운 패턴이 발견되었을 때 기존 규칙과 충돌한다면 어떤 규칙을 따를지 우선순위 가이드도 추가하면 좋을 것 같슴니담
주 작업 내용
Why
How
상세