ureca-corp Skill: Write Book
목적
각 도메인의 Domain Book을 완성하고 최종 검증
철학: "책의 모든 장(chapter)을 완벽하게 마무리"
입력
- 도메인 이름 (예: "users")
- Phase 3 결과 (
domain-model.md) - Phase 4 결과 (
api-spec.md) - SESSION.md (Phase 1-2 결과)
출력
각 도메인당 5개 파일:
README.md(도메인 개요)features.md(기능 정의)domain-model.md✅ (Phase 3 완성)api-spec.md✅ (Phase 4 완성)business-rules.md(비즈니스 규칙)
작동 방식
1. 도메인 의존성 분석
각 domain-model.md에서 다른 도메인을 참조하는지 확인한다:
domain-model.md 검토:
- "번역 기록은 반드시 한 명의 사용자에게 속한다" → translations는 users에 의존
의존성 맵:
users: [] (독립)
translations: [users] (users 완료 후 작성)
missions: [users] (users 완료 후 작성)
phrases: [] (독립)
2. Topological Sort로 작성 순서 결정
의존성이 없는 도메인부터 먼저 작성하고, 의존 도메인은 선행 도메인 완료 후 작성한다:
1단계 (동시): users, phrases
2단계 (동시): translations, missions ← users 완료 후
3. 각 도메인 파일 작성
domain-model.md + api-spec.md + SESSION.md를 읽고 3개 파일을 생성한다:
README.md: 도메인 역할 한 줄 요약 + 목차 + 다른 도메인과의 관계 + 통계 features.md: 기능별 사용자 시나리오 + 범위 밖(Out of Scope) 명시 business-rules.md: 제약 조건 + 상태 전이(있으면) + 권한 규칙 + 예외 처리
4. 최종 검증
5개 파일이 모두 존재하고, 기술 용어가 없으며, 상호 참조가 일관된지 확인한다.
README.md 템플릿
# {Domain} 도메인
> **역할**: {한 줄 설명}
---
## 📚 목차
1. [기능 정의](./features.md) - 이 도메인이 하는 일
2. [도메인 모델](./domain-model.md) - 유비쿼터스 언어 명세
3. [API 명세](./api-spec.md) - API 상세 설계
4. [비즈니스 규칙](./business-rules.md) - 제약조건, 정책
---
## 🔗 도메인 관계
### 의존하는 도메인
- `users` - 사용자 정보 필요
### 이 도메인을 사용하는 도메인
- `missions` - 번역 기록 조회
---
## 📊 요약
- **엔티티 수**: {수}
- **API 수**: {수}
- **상태 전이**: {있음/없음}
---
## 🎯 핵심 가치
{이 도메인의 핵심 가치를 한 문장으로}
사용 예시
# users 도메인
> **역할**: 앱 사용자 관리
---
## 🔗 도메인 관계
### 의존하는 도메인
- 없음 (독립 도메인)
### 이 도메인을 사용하는 도메인
- `translations` - 번역 기록 소유자 확인
- `missions` - 미션 진행자 확인
---
## 📊 요약
- **엔티티 수**: 1개 (User)
- **API 수**: 4개
- **상태 전이**: 없음
---
## 🎯 핵심 가치
사용자 정보를 안전하게 관리하고 다른 도메인에 신원 정보를 제공한다
features.md 템플릿
# {Domain} 기능 정의
## 📋 주요 기능
### 1. {기능 이름}
**설명**: {무엇을 하는가}
**사용자 시나리오**:
\`\`\`
사용자: {상황}
1. {액션 1}
2. {액션 2}
3. 결과: {결과}
\`\`\`
**입력**:
- {입력 1}
- {입력 2}
**출력**:
- {출력 1}
- {출력 2}
---
## 🚫 범위 밖 (Out of Scope)
- {제외 사항 1}
- {제외 사항 2}
사용 예시
# users 기능 정의
## 📋 주요 기능
### 1. 회원가입
**설명**: 새로운 사용자 계정을 생성한다
**사용자 시나리오**:
\`\`\`
여행자: 앱을 처음 사용한다
1. 이메일과 닉네임을 입력한다
2. 선호 언어를 선택한다 (선택사항)
3. 결과: 계정이 생성되고 자동 로그인된다
\`\`\`
**입력**:
- 이메일 (필수)
- 닉네임 (필수)
- 프로필 사진 (선택)
- 선호 언어 (선택, 기본값: 영어)
**출력**:
- 사용자 ID
- 가입 시각
- 프로필 정보
---
## 🚫 범위 밖 (Out of Scope)
- 소셜 로그인 (Google, Apple 등)
- 이메일 인증
- 비밀번호 찾기
- 관리자 권한 관리
business-rules.md 템플릿
# {Domain} 비즈니스 규칙
## 📐 제약 조건
### 1. {제약 이름}
{설명}
**이유**: {왜 이 제약이 필요한가}
---
## 🔄 상태 전이
{있으면 상태 전이 흐름, 없으면 "이 도메인은 상태 전이가 없습니다"}
---
## 🔐 권한 규칙
| 액션 | 권한 | 조건 |
|------|------|------|
| ... | ... | ... |
---
## 💡 비즈니스 로직
### {로직 이름}
\`\`\`
{처리 흐름}
\`\`\`
---
## 🚨 예외 상황 처리
### 1. {예외 상황}
- **대응**: {처리 방법}
사용 예시
# users 비즈니스 규칙
## 📐 제약 조건
### 1. 이메일 유일성
이메일 주소는 시스템 전체에서 고유해야 한다.
**이유**: 이메일을 사용자 식별 수단으로 사용하므로, 중복되면 로그인 시 혼란 발생
---
### 2. 닉네임 길이
닉네임은 최소 1자, 최대 50자여야 한다.
**이유**: 너무 짧으면 식별 불가, 너무 길면 UI 깨짐
---
## 🔄 상태 전이
이 도메인은 상태 전이가 없습니다.
사용자는 "활성" 상태만 가지며, 탈퇴 시 즉시 삭제됩니다.
---
## 🔐 권한 규칙
| 액션 | 권한 | 조건 |
|------|------|------|
| 회원가입 | 누구나 | - |
| 프로필 조회 | 본인 | 자신의 프로필만 |
| 프로필 수정 | 본인 | 자신의 프로필만 |
| 회원 탈퇴 | 본인 | 자신의 계정만 |
---
## 💡 비즈니스 로직
### 선호 언어 기본값
\`\`\`
회원가입 시:
- 선호 언어가 제공되면: 해당 언어 사용
- 제공되지 않으면: 기본값 '영어' 설정
\`\`\`
---
### Cascade 삭제
\`\`\`
회원 탈퇴 시:
1. 사용자의 모든 번역 기록 삭제
2. 사용자의 모든 미션 진행 기록 삭제
3. 사용자 엔티티 삭제
\`\`\`
---
## 🚨 예외 상황 처리
### 1. 이메일 중복
- **대응**: 가입 차단 + "이미 가입된 이메일입니다" 메시지
### 2. 존재하지 않는 사용자 조회
- **대응**: 404 오류 + "존재하지 않는 사용자입니다" 메시지
### 3. 권한 없는 수정 시도
- **대응**: 403 오류 + "본인만 수정할 수 있습니다" 메시지
도메인 관계 추출
다른 도메인을 참조하는지 확인하는 방법: domain-model.md에서 다른 도메인 이름이나 핵심 엔티티를 언급하면 의존성이 있다고 판단한다.
translations/domain-model.md 에서:
"번역 기록은 반드시 한 명의 사용자에게 속한다" → users 참조
→ translations.depends_on = [users]
최종 검증 체크리스트
Domain Book 완성 조건:
파일 존재:
- README.md
- features.md
- domain-model.md
- api-spec.md
- business-rules.md
내용 품질:
- README.md에 도메인 관계 명시
- features.md에 범위 밖 명시
- business-rules.md에 권한 규칙 포함
- 기술 용어 (FastAPI, PostgreSQL, UUID, VARCHAR, JWT, REST, HTTP) 0개
- 오류 메시지가 모두 한글
- api-spec.md와 domain-model.md의 용어가 일치
완성도:
- 모든 엔티티가 domain-model.md에 정의됨
- 모든 API가 api-spec.md에 명시됨
- 도메인 간 참조 관계가 README.md에 반영됨