도메인 모델링은(는) 무엇을 하나요?
이 프로젝트에서 사물이 의미하는 바에 대한 하나의 공유되고 간결한 진실 공급원을 유지하여, 코드, 문서, 티켓, 대화에서 동일한 대상을 동일한 단어로 가리키도록 합니다.
초점: $ARGUMENTS (비어 있으면 이 세션에서 논의 중인 모든 것을 모델링합니다).
암묵적 가정 없음. 용어의 의미는 사용자가 결정합니다. 코드, 문서, 또는 대화에서 추론한 정의, 정식 이름, 동의어, 관계, 카디널리티(cardinality), 불변 조건은 사용자가 확인할 때까지 가정입니다. ✅ 확인됨 · ❓ 미확인 · ❌ 거부됨 으로 추적하고, 확인된 것만 도메인 문서에 사실로 기록합니다.
모델의 위치
GLOSSARY.md또는docs/domain.md가 이미 존재하면 해당 파일을 사용합니다 (기존 파일을 선호하며, 둘 다 생성하지 마십시오).- 그렇지 않으면 아래 구조를 사용하여
docs/domain.md를 생성합니다.
프로세스
- 읽기: 현재 도메인 문서와 해당 개념을 구현하는 코드(타입, 스키마, DB 모델, API 계약)를 읽습니다. 코드는 실제 모델의 증거이고, 문서는 의도된 모델입니다 — 차이(drift)를 기록합니다. 둘 중 어느 것도 사용자의 의도를 알려주지 않으므로, 한쪽을 선택하지 말고 차이에 대해 질문하십시오.
- 후보 용어 추출: 대화, 명세서, 또는 티켓에서 후보 용어를 추출합니다. 각각에 대해 새 용어, 기존 용어, 또는 기존 용어의 동의어인지 제안하고 사용자 확인을 받습니다. 비슷해 보이는 두 단어가 다른 개념일 수 있습니다.
- 모호성 해결: 사용자에게 짧고 구체적인 질문을 던집니다.
- "Workspace는 Organization과 동일한 것입니까, 아니면 하나의 조직이 여러 workspace를 가질 수 있습니까?"
- "Order가 Customer 없이 존재할 수 있습니까? Order에 대해 항상 참이어야 하는 것은 무엇입니까?" 개념당 하나의 정식 이름에 사용자와 합의합니다 (하나를 추천할 수 있음); 거부된 동의어는 Avoid로 나열합니다.
- 경계 정의: 정체성(엔티티 vs 값 객체), 소유권/애그리게이트 루트, 카디널리티, 생명주기/상태, 불변 조건을 정의합니다. 프로젝트에 둘 이상의 바운디드 컨텍스트가 있는 경우 용어가 속한 바운디드 컨텍스트를 명시합니다. 필요한 경우 코드에서 제안하되, 각각을 사용자와 확인하십시오.
- 문서 업데이트: 확인된 항목만 추가합니다 — 최소한의 diff, 섹션 내 알파벳순, 에세이 금지. 정의의 의미가 변경되면 커밋/PR에 그 사실을 명시하고, 해당 용어를 잘못 사용하는 코드를 표시합니다. 사용자가 미해결 항목을 남기고 중단하려면, 해당 항목을 ❓ 표시하여
## Open Questions아래에 추가하고, 용어집에는 절대 넣지 않습니다. - 보고: 추가/변경한 내용과 발견한 코드 ↔ 모델 차이(
file:line포함), 그리고 여전히 열려 있는 ❓ 항목을 보고합니다.
문서 구조 (간결하게 유지)
# 도메인 모델
## 용어집
| 용어 | 정의 | 피해야 할 용어 |
|------|------|----------------|
| Order | 하나 이상의 Product를 구매하려는 고객의 확정된 요청입니다. | purchase, cart |
## 엔티티 및 애그리게이트
### Order (애그리게이트 루트)
- 정체성: `OrderId`
- 포함: OrderLine (1..n)
- 상태: draft → placed → paid → shipped | cancelled
- 불변 조건: total ≥ 0; paid 상태가 아니면 배송 불가
## 관계
- Customer 1 — n Order
## 바운디드 컨텍스트 (선택 사항)
- Billing: Invoice, Payment
규칙: 가능하면 정의당 한 문장; 다른 용어집 용어를 사용하여 정의; 구현 세부 사항은 도메인 자체가 아닌 한 포함 금지 (예: 고객이 보는 ID 형식).