[3주차] 도메인 주도 설계 구현 - 안성훈

.claude/commands/impl-pass-tests.md

@@ -0,0 +1,28 @@
+# 테스트 통과 구현코드 작성
+
+대상 테스트/기능: $ARGUMENTS
+
+모델 고정: `openai/gpt-5.3-codex-spark`
+
+이미 존재하는 테스트 또는 방금 작성한 테스트를 통과하도록 구현코드를 작성해주세요.
+
+## 반드시 따를 규칙
+1. 아키텍처/코딩 규칙 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/AGENTS.md`
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/coding-style.md`
+2. 테스트 정책 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md`
+3. 오버엔지니어링 금지, 최소 변경으로 통과
+4. 민감정보 마스킹/인증 단일화/Locale.ROOT/중복키 409 변환 규칙 준수
+
+## 작업 절차
+1. 실패 테스트 기준으로 필요한 구현 범위만 식별
+2. 구현 코드 수정
+3. 필요한 경우 테스트 fixture만 최소 보정
+4. 관련 테스트만 우선 실행
+5. 통과 확인 후 변경 요약
+
+## 출력
+- 수정 파일 목록
+- 테스트 통과 결과 요약
+- 남은 리스크/추가 필요 테스트

.claude/commands/test-write.md

@@ -0,0 +1,33 @@
+# 테스트코드 작성 (실행 없음)
+
+대상 기능/파일: $ARGUMENTS
+
+모델 고정: `openai/gpt-5.3-codex-spark`
+
+이 프로젝트 규칙에 맞춰 테스트코드만 작성해주세요. 테스트 실행은 하지 않습니다.
+
+## 반드시 따를 규칙
+1. `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md` 우선 적용
+2. 도메인별 레시피 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing-recipes/README.md`
+   - 관련 도메인 레시피(`user.md`, `order.md`, `product-like.md`) 선택 적용
+3. 상태 검증 우선, 단위 테스트는 classist(mock/stub only)
+4. 레이어 정책 준수:
+   - Domain/Domain Service: 단위 테스트
+   - Application Service/Controller: 통합 테스트 코드 형태
+
+## 작성 절차
+1. 기존 테스트 패턴과 네이밍을 먼저 분석
+2. 대상 코드의 happy/unhappy/boundary 케이스 도출
+3. 필수 회귀 항목 반영:
+   - toString 마스킹
+   - raw/encoded 분리
+   - 저장 시점 중복키 예외
+   - 이름 마스킹 1/2/3글자
+4. 테스트 파일 생성/수정
+5. 변경 요약 출력 (무엇을 왜 추가했는지)
+
+## 출력
+- 수정된 테스트 파일 경로 목록
+- 각 테스트의 의도(1줄)
+- 남은 테스트 갭(있으면)

.claude/rules/coding-style.md

@@ -0,0 +1 @@
+../../docs/ai-rules/coding-style.md

.claude/rules/git-workflow.md

@@ -0,0 +1 @@
+../../docs/ai-rules/git-workflow.md

.claude/rules/performance.md

@@ -0,0 +1 @@
+../../docs/ai-rules/performance.md

.claude/rules/security.md

@@ -0,0 +1 @@
+../../docs/ai-rules/security.md

.claude/rules/testing.md

@@ -0,0 +1 @@
+../../docs/ai-rules/testing.md

.claude/skills/requirements-analysis/references/diagram-guide.md

@@ -12,13 +12,12 @@ docs/design/
   04-erd.md
 ```
 
-## 3단계 원칙
+## 2단계 원칙
 
 모든 다이어그램은 반드시 이 순서를 따른다:
 
-1. **이유**: 왜 이 다이어그램이 필요한지, 무엇을 검증하려는지 설명한다
-2. **다이어그램**: Mermaid 문법으로 작성한다
-3. **해석**: "이 구조에서 특히 봐야 할 포인트"를 2~3줄로 설명한다
+1. **다이어그램**: Mermaid 문법으로 작성한다
+2. **해석**: "이 구조에서 특히 봐야 할 포인트"를 2~3줄로 설명한다
 
 ## 생성 순서
 
@@ -32,10 +31,27 @@ docs/design/
 - 전체 로직을 하나의 다이어그램에 그리지 않는다
 - 각 시퀀스는 Happy Path and 주요 Unhappy Path만 표현한다
 - **검증 목적**: 책임 분리, 호출 순서, 트랜잭션 경계 확인
+
+### 화살표(벡터) 표기 규칙
+
+| 화살표 | 의미 | Mermaid 문법 |
+|--------|------|--------------|
+| `──▶` (실선+채움) | 동기 호출 | `->>` |
+| `──>` (실선+열림) | 비동기 호출 | `->` |
+| `- - ▶` (점선) | 응답/반환 | `-->>` |
+
+- 동기 호출은 `->>`, 응답은 `-->>` 로 구분한다
+- 비동기 이벤트는 `-)` 문법을 사용한다
+
+### 액티베이션 바 규칙
+
+- 액티베이션 바는 **처리 중인 상태**를 명시적으로 표현할 때만 사용한다
+- `+`로 활성화 시작, `-`로 활성화 종료: `A->>+B: 요청` / `B-->>-A: 응답`
+- 단순 흐름에서는 생략해도 무방하다 (간결함 우선)
 - **호출 규칙**: Service 간 직접 호출 금지. Facade → Service → Repository 단방향만 허용. Service는 자기 도메인의 Repository만 접근한다. Facade는 Repository를 직접 접근하지 않는다.
 - **메시지 표기 규칙**: API 호출(Client → Controller)은 HTTP 메서드 + 경로를 그대로 표기하고, 내부 호출(Facade ↔ Service ↔ Repository)은 정확한 함수명 대신 한글 설명으로 작성한다. (예: `재고 차감 요청`, `주문 + 주문항목 저장`) 비개발자도 흐름을 이해할 수 있도록 한다.
 - **트랜잭션 위치 규칙**: `@Transactional`은 Domain Service에만 위치한다. Facade에는 절대 `@Transactional`을 두지 않는다. 크로스 도메인 쓰기 시 각 Service가 자기 도메인 내에서 개별 트랜잭션을 관리하고, 실패 시 Facade에서 보상 로직을 처리한다.
-- **표기 금지**: `@Transactional` note, SQL 쿼리 상세, Repository participant. Facade ↔ Service 레벨까지만 표현한다.
+- **표기 금지**: 시퀀스 다이어그램에서는 `@Transactional`을 note/메시지/participant 어디에도 표기하지 않는다. SQL 쿼리 상세, Repository participant도 금지한다. Facade ↔ Service 레벨까지만 표현한다.
 - **자주 겪는 실수**: (1) 세부 흐름 과다로 시퀀스 복잡화 (2) Service만 호출, 도메인 객체 메시지 없음 (3) 추상 수준이 낮아 구현과 괴리 → 유지보수 불가
 - 파일명: `docs/design/02-sequence-diagrams.md` (모든 시퀀스를 하나의 파일에 작성)
 - 최소 2개 이상의 시퀀스 다이어그램을 작성한다
@@ -47,9 +63,6 @@ docs/design/
 
 ## [기능명 1]
 
-### 왜 이 다이어그램이 필요한가
-[이 시퀀스로 검증하려는 것: 책임 분리, 호출 순서, 트랜잭션 경계 등]
-
 ### 시퀀스 다이어그램
 
 \```mermaid
@@ -90,9 +103,6 @@ sequenceDiagram
 ```markdown
 # 클래스 다이어그램
 
-## 왜 이 다이어그램이 필요한가
-[검증하려는 것: 도메인 책임, 의존 방향, 응집도]
-
 ## 클래스 다이어그램
 
 \```mermaid
@@ -125,15 +135,27 @@ classDiagram
 2. `id`, `created_at`, `updated_at`, `*_id`(FK) 컬럼은 생략한다
 3. 카디널리티(1:N, N:M)는 정확히 표현한다
 4. N:M 관계는 조인 테이블을 명시적으로 표현한다 (직접 N:M 연결 금지)
+5. 각 엔티티별 **삭제 전략(Soft/Hard Delete)** 을 명시한다
+
+### 삭제 전략 표기
+
+ERD 작성 후, 각 엔티티의 삭제 전략을 테이블로 정리한다:
+
+| 엔티티 | 삭제 전략 | 이유 |
+|--------|-----------|------|
+| User | Soft Delete | 주문 이력 참조 유지 필요 |
+| Order | Soft Delete | 감사/정산 목적 보관 |
+| Cart | Hard Delete | 임시 데이터, 보관 불필요 |
+
+**판단 기준:**
+- **Soft Delete**: 이력 추적, 감사, 다른 엔티티에서 참조, 복구 가능성 필요 시
+- **Hard Delete**: 임시 데이터, 개인정보 완전 삭제 요구, 참조 없음
 
 **파일 구조:**
 
 ```markdown
 # ERD (논리적 관계)
 
-## 왜 이 다이어그램이 필요한가
-[검증하려는 것: 영속성 구조, 관계의 주인, 정규화 여부]
-
 ## ERD
 
 \```mermaid

.opencode/commands/impl-pass-tests.md

@@ -0,0 +1,28 @@
+# 테스트 통과 구현코드 작성
+
+대상 테스트/기능: $ARGUMENTS
+
+모델 고정: `openai/gpt-5.3-codex-spark`
+
+이미 존재하는 테스트 또는 방금 작성한 테스트를 통과하도록 구현코드를 작성해주세요.
+
+## 반드시 따를 규칙
+1. 아키텍처/코딩 규칙 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/AGENTS.md`
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/coding-style.md`
+2. 테스트 정책 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md`
+3. 오버엔지니어링 금지, 최소 변경으로 통과
+4. 민감정보 마스킹/인증 단일화/Locale.ROOT/중복키 409 변환 규칙 준수
+
+## 작업 절차
+1. 실패 테스트 기준으로 필요한 구현 범위만 식별
+2. 구현 코드 수정
+3. 필요한 경우 테스트 fixture만 최소 보정
+4. 관련 테스트만 우선 실행
+5. 통과 확인 후 변경 요약
+
+## 출력
+- 수정 파일 목록
+- 테스트 통과 결과 요약
+- 남은 리스크/추가 필요 테스트

.opencode/commands/plan.md

@@ -0,0 +1,22 @@
+# 구현/테스트 계획 수립 (코드 수정 없음)
+
+작업 대상: $ARGUMENTS
+
+모델 고정: `openai/gpt-5.3-codex`
+
+이 작업은 **계획만** 작성합니다. 코드/테스트 파일은 수정하지 않습니다.
+
+## 반드시 따를 규칙
+1. 아키텍처/코딩 규칙:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/AGENTS.md`
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/coding-style.md`
+2. 테스트 전략:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md`
+3. 퍼사드는 여러 Application Service 조합이 필요한 경우에만 사용
+4. 계획은 구현 가능한 최소 단위(작업 순서 + 파일 단위 변경점)로 작성
+
+## 출력 형식
+1. 작업 목표 요약 (3줄 이내)
+2. 구현 단계 (순서형)
+3. 테스트 단계 (단위/통합/E2E 구분)
+4. 리스크/의사결정 포인트

.opencode/commands/test-write.md

@@ -0,0 +1,33 @@
+# 테스트코드 작성 (실행 없음)
+
+대상 기능/파일: $ARGUMENTS
+
+모델 고정: `openai/gpt-5.3-codex-spark`
+
+이 프로젝트 규칙에 맞춰 테스트코드만 작성해주세요. 테스트 실행은 하지 않습니다.
+
+## 반드시 따를 규칙
+1. `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md` 우선 적용
+2. 도메인별 레시피 적용:
+   - `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing-recipes/README.md`
+   - 관련 도메인 레시피(`user.md`, `order.md`, `product-like.md`) 선택 적용
+3. 상태 검증 우선, 단위 테스트는 classist(mock/stub only)
+4. 레이어 정책 준수:
+   - Domain/Domain Service: 단위 테스트
+   - Application Service/Controller: 통합 테스트 코드 형태
+
+## 작성 절차
+1. 기존 테스트 패턴과 네이밍을 먼저 분석
+2. 대상 코드의 happy/unhappy/boundary 케이스 도출
+3. 필수 회귀 항목 반영:
+   - toString 마스킹
+   - raw/encoded 분리
+   - 저장 시점 중복키 예외
+   - 이름 마스킹 1/2/3글자
+4. 테스트 파일 생성/수정
+5. 변경 요약 출력 (무엇을 왜 추가했는지)
+
+## 출력
+- 수정된 테스트 파일 경로 목록
+- 각 테스트의 의도(1줄)
+- 남은 테스트 갭(있으면)

.opencode/commands/worktree-create.md

@@ -0,0 +1,17 @@
+# 도메인 작업용 워크트리 생성
+
+입력: `$ARGUMENTS` (예: `user`, `order`)
+
+아래 명령을 **실제로 실행**하세요.
+
+## 실행 명령
+```bash
+git checkout shAn-kor
+git pull origin shAn-kor
+git worktree add ../wt-$ARGUMENTS feature/$ARGUMENTS
+```
+
+## 출력
+- 실행한 명령 목록
+- 생성된 worktree 경로
+- 현재 worktree 목록 (`git worktree list`)

.opencode/commands/worktree-merge.md

@@ -0,0 +1,19 @@
+# 워크트리 작업 종료 후 상위 브랜치 머지
+
+입력: `$ARGUMENTS` (예: `user`, `order`)
+
+아래 명령을 **실제로 실행**하세요.
+
+## 실행 명령
+```bash
+git checkout shAn-kor
+git merge --no-ff feature/$ARGUMENTS
+git push origin shAn-kor
+git worktree remove ../wt-$ARGUMENTS
+git branch -d feature/$ARGUMENTS
+```
+
+## 출력
+- 실행한 명령 목록
+- 머지 커밋 해시
+- 정리 후 worktree 목록 (`git worktree list`)

.opencode/oh-my-opencode.json

@@ -0,0 +1,35 @@
+{
+  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/master/assets/oh-my-opencode.schema.json",
+  "agents": {
+    "hephaestus": {
+      "model": "openai/gpt-5.3-codex",
+      "variant": "medium"
+    },
+    "unspecified-low": {
+      "model": "openai/gpt-5.3-codex-spark",
+      "variant": "medium"
+    },
+    "unspecified-high": {
+      "model": "openai/gpt-5.3-codex",
+      "variant": "medium"
+    }
+  },
+  "categories": {
+    "deep": {
+      "model": "openai/gpt-5.3-codex",
+      "variant": "medium"
+    },
+    "quick": {
+      "model": "openai/gpt-5.3-codex-spark",
+      "variant": "medium"
+    },
+    "unspecified-low": {
+      "model": "openai/gpt-5.3-codex-spark",
+      "variant": "medium"
+    },
+    "unspecified-high": {
+      "model": "openai/gpt-5.3-codex",
+      "variant": "medium"
+    }
+  }
+}

AGENTS.md

@@ -0,0 +1,43 @@
+# AGENTS Router
+
+이 파일은 상세 규칙을 직접 나열하지 않고, 작업 유형에 따라 참조할 규칙 파일을 지정한다.
+
+## Always (항상 적용)
+- 개발 방향/의사결정은 제안까지만 하고, 최종 결정은 사용자 승인 후 반영한다.
+- 요청 범위를 임의로 확장하지 않는다.
+- 실제 동작하는 코드만 작성한다. 임시 목업/가짜 동작으로 완료 처리하지 않는다.
+- 오버엔지니어링을 피한다.
+
+## Core Project Rules (항상 먼저 확인)
+- `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/coding-style.md`
+- `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/git-workflow.md`
+
+## Task-based Rules (작업 유형별 추가 적용)
+- 테스트 작성/수정: `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/testing.md`
+- 성능 이슈/병목 개선: `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/performance.md`
+- 보안 관련 변경(인증/인가/입력 검증): `/Users/anseonghun/Documents/project/loop-pack-be-l2-vol3-java/docs/ai-rules/security.md`
+
+## Non-negotiable Architecture
+- Facade는 여러 Application Service를 조합/오케스트레이션할 때만 사용한다
+- Facade -> Application Service only (Repository/Domain Service 직접 접근 금지)
+- 단일 Application Service 호출만 필요한 유스케이스는 Facade를 만들지 않고 Controller -> Application Service로 직접 연결한다
+- Controller 조합/오케스트레이션 로직 금지 (여러 도메인 데이터 결합/매핑은 Facade 또는 Service로 이동)
+- Application Service -> 자기 도메인 Repository + Domain Service only
+- Application Service 간 직접 호출 금지 (크로스 도메인 협력은 Facade에서 조정)
+- Domain Service는 순수 비즈니스 규칙만 담당 (저장/외부 I/O/트랜잭션 금지)
+- `@Transactional`은 Application Service에만 위치 (Facade/Domain Service 금지)
+- Application/Domain Service의 private 메서드 금지
+- Application/Domain Service에서 같은 클래스의 다른 메서드 직접 호출 금지
+- 유니크 보장은 DB 제약으로 강제하고, 저장 시점 중복키 예외는 409로 변환
+
+## Domain Constraints
+- 결제 시스템 없음: 주문 완료 = 결제 완료
+- 주문 시점 상품 정보 스냅샷 저장
+- 어드민 인증은 `X-Loopers-Ldap` 헤더 기반
+- 포인트 충전 기능은 Scope-out
+
+## Project-specific Guardrails
+- `password`/`token`/`secret` 필드는 `toString()`에서 마스킹
+- 비밀번호 정책 검증은 raw password에서만 수행 (encoded password 제외)
+- 비밀번호 변경은 `@AuthMember` 단일 인증 사용 (body 재인증 금지)
+- 예약어/문자열 케이스 변환은 `Locale.ROOT` 사용