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 ก็ต่อเมื่อครบทั้งสามข้อนี้เท่านั้น:

1. ย้อนกลับยาก — ต้นทุนของการเปลี่ยนใจทีหลังมีนัยสำคัญ
2. ดูแปลกถ้าไม่มี context — คนอ่านในอนาคตจะสงสัยว่า "ทำไมถึงทำแบบนี้?"
3. เป็นผลจาก trade-off จริง — มีทางเลือกอื่นที่เป็นไปได้จริง และคุณเลือกทางนี้ด้วยเหตุผลเฉพาะ

ถ้าขาดข้อใดข้อหนึ่งในสามข้อ ให้ข้าม ADR ไป ใช้ format ใน ADR-FORMAT.md