dev-goraebap/domain-language-extractor

domain-language-extractor 스킬

요구사항 문서에서 도메인의 언어와 경계의 첫 단서를 뽑는다. 핵심 세 산출:

1. 용어집(UL 사전) — 각 용어의 정의·별칭·주요 맥락
2. 동의어·동음이의어 — 서브도메인 분리의 가장 강력한 단서
3. 경량 이벤트 흐름 — 과거형 이벤트만 시간 순. 정책·분기는 [5]의 몫.

이 정보로 서브도메인 후보(Core/Supporting/Generic 분류 전, 문제 공간의 단위)를 제안한다. BC 후보가 아니다 — BC는 [4] context-designer에서 분류된 서브도메인으로부터 설계된다.

---

대화 UX 규약 (필수)

• 카테고리 선택은 숫자 메뉴. 자유 입력 금지.
• 1문 1답 기본. 단순 Yes/No만 2~3개까지 번호 달아 묶기 허용.
• 진행 표시: [Q 3/12 · 근거: ...]
• "나중에" / "모름" / "스킵" 항상 허용 → ⚠️ 미정으로 산출물에 기록.
• 자가 진단·평가는 ✅/⚠️/❌ 3단계. 숫자 점수 금지.
• 정답보다 올바른 질문 생성이 스킬의 핵심 가치.

---

1. 언제 트리거하는가

• /ddd-workshop:domain-language-extractor
• requirements-refiner 출력 직후
• "용어집 추출", "Ubiquitous Language", "서브도메인 후보 찾아줘"
• 기존 ubiquitous-language.md가 있고 "업데이트" → --update 모드

부분 진입 허용: requirements.md가 없어도 PRD·요구사항 설명으로 동작. 단 서브도메인 후보의 근거가 약해짐.

---

2. 입력

• docs/requirements.md (requirements-refiner 산출) — 주 입력
  • ## 도메인 브리프의 "후속 스킬 힌트 → domain-language-extractor" 섹션 참고
• 또는 사용자 제공 문서

---

3. Step 0 — Upstream 일관성 스캔 (자동)

시작 시 다음을 자동 점검:

1. requirements.md의 updated_at을 자기 sources: 기록과 비교 → 새로우면 stale 경고.
2. requirements.md의 주요 용어(맥락·Why·액터에 등장한 핵심 명사)를 목록화 → 본 작업 중 같은 용어를 다른 형태로 쓰면 경고.
3. ⚠️ 미정 항목이 많으면 "진행할까 먼저 [1]에 복귀할까?" 선택지 제시.

결과를 사용자에게 간단히 공개:

📋 Upstream 스캔 결과
- requirements.md: 최신 (OK)
- 핵심 용어 14개 로드 (주문, 회원, 상품, ...)
- ⚠️ 미정 항목 3개 있음. 진행하시겠습니까? (1) 진행 2) [1]로 복귀 3) 미정만 확인)

---

4. 진행 단계

Step 1 — 용어 후보 추출 (내부)

요구사항에서 명사와 동사를 훑어 후보 20~40개 추출. 일반 동사(만들다/보다)는 제외. 도메인성 있는 단어 우선. 이 단계는 사용자에게 안 보임.

Step 2 — 용어 정의 작성 (대화)

후보를 5~10개씩 묶어 제시하고 사용자 확인. (예외적으로 묶기 허용, 각 항목 번호 필수)

[Batch 1/4] 아래 용어의 정의를 확인해주세요. 각각 번호로 답해주세요.

1) 주문 — [에이전트 제안 정의]
2) 회원 — [제안]
3) 상품 — [제안]
...

답변 방식 예:
"1번 OK, 2번은 '가입 사용자'로 수정, 3번은 미정"
"전부 OK"
"1,2 OK. 3번은 내가 다시 정의함: ..."

사용자가 수정/보완하면 반영. "미정"은 ⚠️ 미정으로 남김.

Step 3 — 동의어 감지 (대화, 1문 1답)

같은 개념이 다른 이름으로 쓰이는지 점검. 전형 예시:

• 사용자 / 고객 / 회원 / 유저
• 주문 / 발주
• 상품 / 품목 / 제품

감지되면 1문 1답으로 묻기:

[Q 5/20 · 근거: 동의어 감지]
문서에 "사용자"와 "회원"이 섞여 나옵니다. 두 용어가 같은 개념인가요?

1) 같은 개념 (하나로 통일하겠음 → 용어 선택)
2) 다른 역할 (로그인 전 / 가입 후 등 구분)
3) 모름
4) 나중에

임의 통합 금지. 확정되면 용어집에 반영.

Step 4 — 동음이의어 감지 ⭐ (서브도메인 분리의 1순위 증거)

같은 용어가 맥락별로 다른 속성 집합을 갖는지 확인.

감지 방법 (내부):

1. 각 용어가 등장하는 요구사항 문장들을 모음.
2. 각 등장에서 그 용어에 어떤 속성이 필요한지 본다.
3. 속성 집합이 크게 다르면 → 동음이의어 후보.

예시:

• "상품" in 카탈로그: 제목·설명·이미지·가격(정가)
• "상품" in 주문: 판매가·옵션·재고 스냅샷
• "상품" in 배송: 무게·부피·포장

감지된 각 후보를 사용자에게 제시 + 이게 서브도메인 분리 신호임을 명시.

Step 5 — 경량 이벤트 흐름 (과거형 이벤트만)

요구사항에서 "이런 일이 일어난다"를 과거형 이벤트로 변환해 시간 순 나열.

• "회원이 주문을 넣는다" → 주문됨
• "결제가 완료되면 알림" → 결제완료됨, 알림전송됨

여기서는 이벤트만. 정책·커맨드·분기는 [5] aggregate-designer에서. 이유: 지금은 서브도메인 후보의 증거로만 쓰므로 복잡도 최소화.

이벤트를 시간 순으로 배열해 사용자 확인. 업계 표준 프로세스(requirements의 도메인 브리프 참조) 대비 명백한 누락만 1~2개 지적.

Step 6 — 서브도메인 후보 제안 (BC 아님!)

위 증거를 종합해 서브도메인 후보를 제안.

서브도메인 후보 도출 근거:

1. 동음이의어 — 같은 용어가 다른 맥락에서 다른 속성 → 각 맥락이 별도 서브도메인일 가능성 높음.
2. 응집된 개념 그룹 — 자주 함께 등장하는 용어들.
3. 이벤트 클러스터 — 함께 발생하는 이벤트 덩어리.
4. 언어 변화 — 문서에서 어휘·추상화 수준이 달라지는 지점.
5. 책임·조직 (사내 맥락) — 부서별 관심사 차이.

사용자에게 제시:

🎯 서브도메인 후보 (문제 공간. BC는 다음 스킬에서 설계됩니다)

후보 A: 상품 노출
  - 포함 개념: 상품(전시정보), 카테고리, 검색
  - 주요 이벤트: 상품등록됨, 상품수정됨
  - 증거: 동음이의어("상품"), 응집된 개념 그룹

후보 B: 구매 거래
  - 포함 개념: 주문, 결제, 장바구니
  - 주요 이벤트: 주문됨, 결제완료됨, 결제실패됨
  - 증거: 이벤트 클러스터, 언어 변화(가격→판매가)

후보 C: 물류
  - 포함 개념: 배송, 주소, 무게/부피
  - 증거: 동음이의어("상품"), 언어 변화

이 후보들이 맞나요? 조정이 필요한 부분이 있나요?

---

5. 산출물

기본 경로 docs/ubiquitous-language.md.

---
skill: domain-language-extractor
version: 0.2.0
context: {학습|개인|사내|B2B|B2C}
confidence: {high|medium|low}
sources:
  - path: docs/requirements.md
    skill: requirements-refiner
    version: 0.2.0
    updated_at: YYYY-MM-DD
next_suggested: subdomain-classifier
updated_at: YYYY-MM-DD
---

# Ubiquitous Language

## 용어집

| 용어 | 정의 | 별칭 | 주요 맥락 | 업계 표준 대응 |
|---|---|---|---|---|
| 주문 | 회원이 상품을 구매하기 위해 확정한 단위 | — | 결제·배송·환불 | Order |
| ... | ... | ... | ... | ... |

## ⚠️ 동의어 확정 내역
- "사용자" + "회원" → "회원"으로 통일 (역할 구분 없음 확인)
- "상품" + "품목" → 맥락별 유지 (아래 동음이의어 참조)

## ⚠️ 동음이의어 (서브도메인 분리 신호)

### "상품"
- 상품 노출 맥락: 제목·설명·이미지·정가
- 구매 거래 맥락: 판매가·옵션·재고 스냅샷
- 물류 맥락: 무게·부피·포장

## 경량 이벤트 흐름

시간 순 (정책·분기는 [5]에서 상세화):

주문됨 → 재고확인됨 → 결제완료됨 → 출고요청됨 → 발송됨 → 배송완료됨 주문취소됨 → 환불완료됨

## ⚠️ 업계 표준 대비 누락 가능성
- 분쟁 조정 단계 (domain-brief § ... 참조)

## 서브도메인 후보 ⭐

(BC 후보 아님! 문제 공간의 단위. Core/Supporting/Generic 분류는 subdomain-classifier가 담당.)

### [A] 상품 노출
- 포함 개념: 상품(전시정보), 카테고리, 검색
- 주요 이벤트: 상품등록됨, 상품수정됨
- 증거: 동음이의어("상품"), 응집된 개념 그룹

### [B] 구매 거래
- 포함 개념: 주문, 결제, 장바구니
- 주요 이벤트: 주문됨, 결제완료됨
- 증거: 이벤트 클러스터

### [C] 물류
- 포함 개념: 배송, 주소
- 증거: 동음이의어, 언어 변화

### [D] 분쟁 조정 ⚠️ 브리프 기반 보강
- 증거: domain-brief 업계 표준 대비 누락 경고

## 미정
- ⚠️ ...

## 다음 단계
→ `subdomain-classifier`로 위 서브도메인 후보를 Core/Supporting/Generic 분류.

---

6. 업데이트 모드 (--update)

기존 ubiquitous-language.md가 있고 요청되면:

1. upstream requirements.md의 updated_at 확인 → 변경됐으면 사용자에게 알림.
2. 사용자에게 "무엇을 업데이트할까요?" (숫자 메뉴):

   1) 새 용어 추가
   2) 기존 용어 정의 수정
   3) 동의어/동음이의어 재감지
   4) 이벤트 흐름 갱신
   5) 서브도메인 후보 재검토
   

3. 해당 섹션만 delta 질문 → 반영.

---

7. 강제 체크리스트 (산출물 내기 전)

□ Step 0 upstream 스캔 수행됨
□ 용어 후보 최소 10개 이상 (작은 PRD면 더 적어도 OK)
□ 각 용어에 "정의" 필드
□ 동의어 후보 최소 1종 점검됨 (사용자 확정)
□ 동음이의어 후보 최소 1종 점검됨 (가장 중요한 서브도메인 분리 신호)
□ 경량 이벤트 흐름 제시됨
□ 서브도메인 후보 최소 2개 (단일은 드뭄)
□ 각 후보에 "증거 (판별 기준)" 태그
□ 산출물에 "BC 후보"가 아니라 "서브도메인 후보"라고 명시됨 ← 필수!

---

8. 맥락별 조정

| 맥락 | 용어 수 | 업계 표준 대조 | 서브도메인 후보 수 | |---|---|---|---| | 학습 | 10~15 | 생략 | 1~2 | | 개인 | 15~25 | 가볍게 | 2~3 | | 사내 | 30+ | 강함 | 3~6 | | B2B | 30+ | 강함 | 3~6 | | B2C | 20~30 | 중간 | 3~5 |

---

9. 절대 하지 말 것

• 산출물에 "BC 후보" 라고 쓰기. 반드시 "서브도메인 후보". (BC는 해결 공간. [4] context-designer에서 분류된 서브도메인으로부터 설계됨.)
• 동의어 후보를 사용자 확인 없이 임의 통합.
• 업계 표준 용어를 사용자 확인 없이 강제.
• 동음이의어 감지를 생략 (가장 중요한 서브도메인 분리 신호).
• [5]에서 할 정책·분기·커맨드를 여기서 다루기.
• 용어 정의를 일반 사전 정의로 베끼기.
• 한 메시지에 자유 서술 질문을 여러 개 쏟기.
• Step 0 upstream 스캔 생략.