도메인 모델링은(는) 무엇을 하나요?
설계 과정에서 프로젝트의 도메인 모델을 능동적으로 구축하고 다듬으세요. 이는 능동적인 훈련입니다: 용어에 이의를 제기하고, 경계 사례 시나리오를 발명하며, 용어집과 결정사항을 명확해지는 즉시 기록하는 것입니다. (단순히 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를 의미하는 것 같습니다. 어느 쪽인가요?"
모호한 언어 정제하기
사용자가 모호하거나 과부하된 용어를 사용하면 정확한 표준 용어를 제안하세요. "'계정'이라고 말씀하시는데, 고객을 의미하나요 아니면 사용자를 의미하나요? 그 둘은 다른 것입니다."
구체적인 시나리오 논의하기
도메인 관계가 논의될 때는 구체적인 시나리오로 스트레스 테스트를 하세요. 경계 사례를 탐색하고 사용자가 개념 간의 경계를 정확히 정의하도록 강제하는 시나리오를 발명하세요.
코드와 상호 참조하기
사용자가 어떤 것이 작동하는 방식을 설명할 때 코드가 일치하는지 확인하세요. 모순을 발견하면 표면화하세요: "코드는 전체 주문을 취소하지만, 방금 부분 취소가 가능하다고 말씀하셨습니다. 어느 쪽이 맞나요?"
GLOSSORY.md 인라인 업데이트하기
용어가 결정되면 바로 GLOSSARY.md를 업데이트하세요. 모아서 처리하지 말고 발생하는 즉시 캡처하세요. GLOSSARY-FORMAT.md의 형식을 사용하세요.
GLOSSARY.md에는 구현 세부 사항이 전혀 없어야 합니다. GLOSSARY.md를 명세서, 스크래치 패드 또는 구현 결정을 위한 저장소로 취급하지 마세요. 이는 용어집이며 그 외에는 아무것도 아닙니다.
ADR은 제한적으로 제공하기
다음 세 가지 조건이 모두 참일 때만 ADR 생성을 제안하세요:
- 되돌리기 어려움: 나중에 마음을 바꾸는 비용이 의미 있음
- 맥락 없이 놀라움: 미래의 독자가 "왜 이렇게 했을까?"라고 궁금해할 것임
- 실제 트레이드오프의 결과: 진정한 대안이 있었고 특정 이유로 하나를 선택함
세 가지 중 하나라도 없으면 ADR을 건너뛰세요. ADR-FORMAT.md의 형식을 사용하세요.