Domain Storytelling and Scenarios#

Event timeline บอกว่า Transfer Reviewed แต่ไม่บอกว่าใครเปิด spreadsheet, ใครโทรหาลูกค้า, เอกสารใดถูกส่งต่อ และระบบใดต้องคัดลอก reference ด้วยมือ Domain Storytelling ช่วยให้คนทำงานจริง เล่า scenario ทีละกิจกรรม ทำให้ actor, work object และ handoff ที่ซ่อนใน process diagram ปรากฏ

เล่า 1 เรื่อง ไม่ใช่อธิบายระบบทั่วไป#

Domain Storytelling Quick-Start Guide อธิบายการให้ Domain Expert เล่าเรื่อง concrete และ moderator วาดสิ่งที่ได้ยิน เริ่มด้วยคำถาม:

เล่าครั้งล่าสุดที่ provider report ไม่ตรงกับ internal transfer ให้ฟัง ตั้งแต่ใครสังเกตเห็น จนรายการถูกปิด

หลีกเลี่ยง “ปกติเราทำอย่างไร” เพราะผู้เล่าจะรวมหลาย variation และข้ามงานที่คิดว่าทุกคนรู้ Concrete instance มีวันที่, role, artifact และข้อยกเว้นให้ถามต่อได้

Grammar ของ Story#

ใช้ 3 องค์ประกอบ:

• Actor — คน, ทีม หรือ system ที่ทำ activity
• Work Object — information/document/thing ที่ถูกสร้าง อ่าน เปลี่ยน หรือส่งต่อ
• Activity — verb phrase ที่ actor ทำกับ work object

ตัวอย่าง:

1. Reconciliation Analyst compares Settlement Report with Transfer Records
2. Analyst marks an Unmatched Execution
3. Payment Operations requests Provider Evidence
4. Provider Portal returns a Capture Record
5. Ledger Operations posts an approved Correction
6. Analyst closes the Reconciliation Case

ให้ผู้เล่าเลือกศัพท์ อย่าแปลง Unmatched Execution เป็น transaction_error เพราะ database ใช้ชื่อนั้น ทันที ถามว่า work object เปลี่ยน owner/meaning ตรงไหน และ activity ใดเป็น decision เทียบกับ data entry

System map

Diagram นี้ไม่ใช่ system sequence แต่เป็นประโยคของ Domain Storytelling: actor ทำ activity กับ work object ลูกศรที่เปลี่ยน actor คือ handoff ซึ่งต้องถามเรื่อง meaning, authority และเวลารอ

Scope และ Perspective#

วาด story แยกตาม perspective:

• customer completes a transfer
• Operations repairs an indeterminate execution
• Risk reviews a policy exception
• Finance closes daily settlement

ไม่ควรวาด “ master story” ที่รวมทุก role จนไม่มีใครยืนยันได้ Story 2 ชุดอาจขัดกัน เช่น Payment บอกว่างานจบเมื่อ provider accepts แต่ Finance บอกว่ายังเปิดจน settlement matches ความขัดแย้งนี้ คือ evidence ของ language/lifecycle boundary

ถามต่อที่ Handoff#

ทุกลูกศรระหว่าง actors ให้ถาม:

1. อะไรถูกส่งจริง: ID, snapshot, document หรือคำสั่ง
2. ผู้รับตีความคำ/สถานะอย่างไร
3. ผู้ส่งยังแก้สิ่งนั้นได้หรือไม่
4. ถ้าข้อมูลช้า/ซ้ำ/หาย ใครตาม
5. Service-level expectation และ escalation คืออะไร
6. เป็น collaboration, approval หรือ simple consumption

Handoff สูงไม่แปลว่าต้องรวมทีมเสมอ บางจุดต้องมี separation of duties หรือ independent control แต่ต้องทำ cost และ responsibility ให้ชัด

Story Variation และ Exception#

หลังเล่า case แรก ถาม variation ทีละแกน:

• small vs large amount โดยไม่ invent threshold
• domestic vs cross-border jurisdiction
• provider known failure vs unknown outcome
• new vs existing beneficiary
• automated vs manual review
• same-day vs late settlement report

สร้าง story แยกหาก actors/objects/meaning เปลี่ยนมาก อย่าเพิ่ม diamond 20 จุดในภาพเดียว Variation เป็น input ที่ดีต่อ Example Mapping และ boundary stress test

จาก Story สู่ Model Evidence#

Story ไม่พิสูจน์ Bounded Context แต่ให้ concrete evidence ที่ Context Map ต้องอธิบาย

แบบฝึกปฏิบัติ: Reconciliation Story#

สัมภาษณ์หรือ role-play 2 perspectives: Payment Operations และ Finance โดยใช้ scenario “ settlement report มี provider reference ที่ internal system หาไม่พบ” ส่งมอบ:

Story scope and concrete instance:
Actors:
Activities in order:
Work objects and who owns each:
Handoffs and failure expectations:
Words used differently:
Manual control and policy source:
Boundary hypotheses:
Questions and named owners:

จากนั้นเปรียบเทียบ stories และวง 3 จุดที่ perspective ขัดกัน สิ่งที่ขัดกันสำคัญกว่าความสวยของภาพ

รายการตรวจสอบ#

• story เป็น concrete instance ไม่ใช่ process เฉลี่ย
• Domain Expert เป็นผู้เล่าและใช้ภาษาของตน
• actor, activity และ work object แยกชัด
• handoff ระบุข้อมูล ความหมาย และ failure owner
• variation ถูกแยกแทนการรวม diamond จำนวนมาก
• manual work ถูกตรวจว่าเป็น control หรือ waste
• story ให้ evidence แต่ไม่ประกาศ boundary อัตโนมัติ

อ่านเพิ่มเติม#

• Domain Storytelling Quick-Start Guide — วิธีจากผู้สร้าง practice
• Domain Storytelling — resources และ tooling ทางการ
• Collaborative Modeling Workshop Preparation Canvas — เตรียม decision question และ participants