domain-modeling

name	domain-modeling
description	프로젝트의 도메인 모델을 구축하고 다듬는다. 사용자가 도메인 용어나 유비쿼터스 언어를 확정하거나, 아키텍처 결정을 기록하거나, 다른 스킬이 도메인 모델을 유지해야 할 때 사용.

이 스킬을 시작하면 가장 먼저 EnterPlanMode 도구를 호출해 plan mode로 진입하라.

도메인 모델링(Domain Modeling)

• 설계하면서 도메인 모델을 적극적으로 구축하고 다듬는다
• 용어에 도전하고, 엣지 케이스 시나리오를 만들고, 확정된 즉시 용어집과 결정을 기록한다
• CONTEXT.md를 읽는 것만으로는 이 스킬이 아님
• 이 스킬은 모델을 변경할 때 사용. 단순히 읽을 때는 아님

파일 구조

대부분의 저장소는 단일 컨텍스트를 가짐:

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

루트에 CONTEXT-MAP.md가 있으면 저장소에 여러 컨텍스트가 존재. 맵은 각 위치를 가리킴:

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← 시스템 전체 결정
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 컨텍스트별 결정
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

• 파일은 쓸 내용이 생길 때만 생성
• CONTEXT.md가 없으면 첫 번째 용어가 확정될 때 생성
• docs/adr/가 없으면 첫 번째 ADR이 필요할 때 생성

세션 중 행동 지침

용어집과 대조해 검증

• 사용자가 CONTEXT.md의 기존 언어와 충돌하는 용어를 쓰면 즉시 지적
• 예: "용어집에서 'cancellation'은 X로 정의되어 있는데 Y를 의미하는 것 같습니다 — 어느 쪽인가요?"

모호한 언어 정제

• 사용자가 모호하거나 과부하된 용어를 쓰면 정확한 표준 용어 제안
• 예: "'account'라고 하셨는데 — Customer를 뜻하나요, User를 뜻하나요? 둘은 다릅니다."

구체적인 시나리오로 검증

• 도메인 관계를 논의할 때 구체적인 시나리오로 스트레스 테스트
• 엣지 케이스를 탐색하는 시나리오를 직접 만들어 사용자가 개념 경계를 명확히 하도록 유도

코드와 교차 검증

• 사용자가 어떻게 작동한다고 말하면 코드가 동의하는지 확인
• 모순 발견 시 표면화: "코드는 전체 Order를 취소하는데, 방금 부분 취소가 가능하다고 했습니다 — 어느 쪽이 맞나요?"

CONTEXT.md 즉시 업데이트

• 용어가 확정되면 바로 CONTEXT.md를 업데이트
• 일괄 처리 금지 — 발생하는 즉시 기록
• 형식은 CONTEXT-FORMAT.md 참고
• CONTEXT.md에 구현 세부사항 절대 포함 금지
• 스펙, 메모장, 구현 결정 저장소로 쓰지 말 것 — 용어집 역할만

ADR은 신중하게 제안

다음 세 가지 모두 해당할 때만 ADR 생성 제안:

1. 되돌리기 어려움 — 나중에 마음을 바꾸는 비용이 큼
2. 맥락 없이는 놀라움 — 미래의 독자가 "왜 이렇게 했지?"라고 의아해할 것
3. 실제 트레이드오프의 결과 — 진짜 대안이 있었고 특정 이유로 하나를 선택

• 셋 중 하나라도 빠지면 ADR 건너뜀
• 형식은 ADR-FORMAT.md 참고