도메인 모델링
설계하는 동안 프로젝트의 도메인 모델을 적극적으로 구축하고 다듬습니다. 이는 능동적인 활동입니다: 용어에 이의를 제기하고, 경계 사례 시나리오를 발명하며, 용어가 명확해지는 즉시 용어집과 결정 사항을 기록합니다. (단순히 어휘를 위해 GLOSSARY.md를 읽는 것은 이 스킬이 아닙니다. 어떤 스킬이든 할 수 있는 한 줄짜리 습관입니다. 이 스킬은 모델을 소비하는 것이 아니라 변경할 때를 위한 것입니다.)
파일 구조
대부분의 저장소는 단일 컨텍스트를 가집니다:
/
├── GLOSSARY.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
루트에 GLOSSARY-MAP.md가 존재하면, 저장소에 여러 컨텍스트가 있는 것입니다. 맵은 각 컨텍스트의 위치를 가리킵니다:
/
├── GLOSSARY-MAP.md
├── docs/
│ └── adr/ ← 시스템 전체 결정 사항
├── src/
│ ├── ordering/
│ │ ├── GLOSSARY.md
│ │ └── docs/adr/ ← 컨텍스트별 결정 사항
│ └── billing/
│ ├── GLOSSARY.md
│ └── docs/adr/
파일은 작성할 내용이 있을 때만 지연 생성합니다. GLOSSARY.md가 없으면 첫 번째 용어가 확정될 때 생성합니다. docs/adr/가 없으면 첫 번째 ADR이 필요할 때 생성합니다.
세션 중
용어집에 대해 이의 제기
사용자가 GLOSSARY.md의 기존 용어와 충돌하는 용어를 사용하면, 즉시 지적하세요. "용어집에서는 '취소'를 X로 정의했지만, 당신은 Y를 의미하는 것 같습니다. 어떤 것인가요?"
모호한 언어 명확히 하기
사용자가 모호하거나 다의적인 용어를 사용하면, 정확한 정식 용어를 제안하세요. "'계정'이라고 말씀하셨는데, 고객을 의미하나요 아니면 사용자를 의미하나요? 이 둘은 다른 것입니다."
구체적인 시나리오 논의
도메인 관계가 논의될 때, 특정 시나리오로 스트레스 테스트를 수행하세요. 경계 사례를 탐구하고 사용자가 개념 간의 경계를 정확히 정의하도록 강제하는 시나리오를 발명하세요.
코드와 상호 참조
사용자가 어떤 방식으로 작동한다고 말하면, 코드가 동의하는지 확인하세요. 모순을 발견하면 표면화하세요: "코드는 전체 주문을 취소하지만, 방금 부분 취소가 가능하다고 말씀하셨습니다. 어떤 것이 맞나요?"
GLOSSARY.md 인라인 업데이트
용어가 확정되면, 즉시 GLOSSARY.md를 업데이트하세요. 일괄 처리하지 말고, 발생하는 대로 캡처하세요. GLOSSARY-FORMAT.md의 형식을 사용하세요.
GLOSSARY.md에는 구현 세부 사항이 전혀 포함되어서는 안 됩니다. GLOSSARY.md를 명세서, 스크래치 패드 또는 구현 결정의 저장소로 취급하지 마세요. 이는 오직 용어집일 뿐입니다.
ADR은 신중하게 제안
다음 세 가지가 모두 참일 때만 ADR 생성을 제안하세요:
- 되돌리기 어려움: 나중에 마음을 바꾸는 비용이 의미 있음
- 맥락 없이 놀라움: 미래의 독자가 "왜 이렇게 했을까?"라고 궁금해할 것임
- 실제 트레이드오프의 결과: 진정한 대안이 있었고 특정 이유로 하나를 선택함
셋 중 하나라도 빠지면 ADR을 건너뛰세요. ADR-FORMAT.md의 형식을 사용하세요.