| name | domain-modeling |
| description | สร้างและลับ domain model ของ project ให้คม ใช้เมื่อ user อยาก pin down ศัพท์ของ domain หรือ ubiquitous language, บันทึกการตัดสินใจเชิงสถาปัตยกรรม หรือเมื่อ skill อื่นต้องดูแล domain model |
Domain Modeling
สร้างและลับ domain model (โมเดลความเข้าใจในโดเมนธุรกิจ) ของ project ให้คมอย่างจริงจังระหว่างที่ออกแบบ นี่คือวินัยแบบ active — ท้าทายคำศัพท์ คิด scenario แบบ edge case ขึ้นมาทดสอบ และเขียน glossary กับการตัดสินใจลงไฟล์ทันทีที่มันตกผลึก (แค่ อ่าน CONTEXT.md เพื่อเอาคำศัพท์มาใช้ไม่นับเป็น skill นี้ — นั่นเป็นนิสัยบรรทัดเดียวที่ skill ไหนก็ทำได้ skill นี้มีไว้ตอนที่คุณกำลังเปลี่ยนตัว model ไม่ใช่แค่ใช้งานมัน)
โครงสร้างไฟล์
repo ส่วนใหญ่มี context เดียว:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
ถ้ามี CONTEXT-MAP.md อยู่ที่ root แปลว่า repo มีหลาย context ตัว map จะชี้ว่าแต่ละ context อยู่ตรงไหน:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
สร้างไฟล์แบบ lazy — สร้างต่อเมื่อมีอะไรจะเขียนจริง ๆ ถ้ายังไม่มี CONTEXT.md ให้สร้างตอนที่คำแรกถูกเคาะข้อสรุป ถ้ายังไม่มี docs/adr/ ให้สร้างตอนที่ต้องเขียน ADR อันแรก
ระหว่าง session
ท้าทายกับ glossary
เมื่อ user ใช้คำที่ขัดกับภาษาที่มีอยู่แล้วใน CONTEXT.md ให้ท้วงทันที "glossary ของคุณนิยาม 'cancellation' ว่า X แต่ดูเหมือนคุณหมายถึง Y — ตกลงอันไหนกันแน่?"
ลับภาษาที่คลุมเครือให้คม
เมื่อ user ใช้คำที่กำกวมหรือความหมายซ้อนทับกัน ให้เสนอคำ canonical ที่แม่นยำ "คุณพูดว่า 'account' — หมายถึง Customer หรือ User? สองอย่างนี้เป็นคนละเรื่องกัน"
คุยด้วย scenario ที่เป็นรูปธรรม
เมื่อกำลังคุยเรื่องความสัมพันธ์ใน domain ให้ stress-test ด้วย scenario เฉพาะเจาะจง คิด scenario ที่จิ้มไปที่ edge case และบังคับให้ user ต้องแม่นยำกับเส้นแบ่งระหว่าง concept
Cross-reference กับ code
เมื่อ user บอกว่าอะไรทำงานยังไง ให้เช็คว่า code เห็นตรงกันไหม ถ้าเจอความขัดแย้ง ให้ยกขึ้นมา: "code ของคุณ cancel ทั้ง Order แต่คุณเพิ่งบอกว่า cancel บางส่วนได้ — อันไหนถูก?"
อัปเดต CONTEXT.md ทันทีในบทสนทนา
เมื่อคำหนึ่งได้ข้อสรุปแล้ว ให้อัปเดต CONTEXT.md ตรงนั้นเลย อย่าสะสมไว้ทำทีเดียว — เก็บมันตอนที่มันเกิดขึ้น ใช้ format ใน CONTEXT-FORMAT.md
CONTEXT.md ต้องปลอดรายละเอียด implementation โดยสิ้นเชิง อย่าใช้ CONTEXT.md เป็น spec, เป็นกระดาษทด หรือเป็นที่เก็บการตัดสินใจด้าน implementation มันคือ glossary และเป็นแค่นั้น
เสนอ ADR แบบระมัดระวัง
เสนอสร้าง ADR ก็ต่อเมื่อครบทั้งสามข้อนี้เท่านั้น:
- ย้อนกลับยาก — ต้นทุนของการเปลี่ยนใจทีหลังมีนัยสำคัญ
- ดูแปลกถ้าไม่มี context — คนอ่านในอนาคตจะสงสัยว่า "ทำไมถึงทำแบบนี้?"
- เป็นผลจาก trade-off จริง — มีทางเลือกอื่นที่เป็นไปได้จริง และคุณเลือกทางนี้ด้วยเหตุผลเฉพาะ
ถ้าขาดข้อใดข้อหนึ่งในสามข้อ ให้ข้าม ADR ไป ใช้ format ใน ADR-FORMAT.md
