Collaborative Modeling in Practice#

เอกสาร requirement ของ chargeback เขียนว่า “เมื่อ dispute สำเร็จให้คืนเงิน” แต่ Product หมายถึง issuer ตัดสินแล้ว Operations หมายถึง case ปิด ส่วน Wallet หมายถึง reversal ถูก post หาก Architect อ่านเอกสารคนเดียวแล้ววาด Bounded Context ความขัดแย้งนี้จะถูกซ่อนจน integration test หรือ production Collaborative Modeling มีเป้าหมายทำให้หลายมุมมองชนกันเร็วและปลอดภัย

เลือก Workshop ให้ตรงคำถาม#

EventStorming มีระดับการสำรวจต่างกัน อย่าใช้ session เดียวทำทุกอย่าง:

หน้า Official EventStorming Resources ระบุว่า Big Picture เหมาะกับการสำรวจวงกว้างและควรให้ความสำคัญกับ facilitation โดยเฉพาะเมื่อทำออนไลน์ ส่วน AWS ก็แนะนำ event storming เป็นวิธีให้ domain และ software experts สำรวจความซับซ้อนร่วมกัน ใน Hexagonal Architecture Best Practices นี่เป็นหลักฐานว่า practice ถูกใช้ใน industry guidance แต่ไม่ได้แปลว่า EventStorming เป็นข้อบังคับ ของ DDD ทีมอาจใช้ Domain Storytelling, Example Mapping, user journey หรือ interview ได้

เตรียมคนและ Scope#

เริ่มด้วย business question ที่ขอบเขตพอจะจบ เช่น “ตั้งแต่ Customer ขอ partial refund จน Finance reconcile รายการ” ไม่ใช้หัวข้อ “ออกแบบ Payments ใหม่” ซึ่งกว้างเกินไป

เชิญคนที่ถือความรู้คนละชนิด:

• Business/Product owner ของ outcome และ priority
• Operations/Customer Support ที่เห็น exception และ manual workaround
• Finance/Risk/Compliance ที่ตอบ policy source และ evidence
• Engineer/Data/SRE ที่รู้ behavior จริงของ legacy และ failure
• Facilitator ที่ไม่มีแรงจูงใจบังคับ solution ของตน

หาก policy owner มาไม่ได้ ให้ติดคำถามพร้อมชื่อผู้รับผิดชอบ ห้ามให้เสียงดังที่สุดในห้องเติม threshold หรือ compliance rule แทน การมีผู้บริหารครบแต่ไม่มีเจ้าหน้าที่ที่ทำงานจริงก็ทำให้ happy path กลบ exception เช่นเดียวกัน

เตรียม pre-read ไม่เกิน 1 หน้า: purpose, start/end event, terminology ที่ยังขัดแย้ง, known constraints และสิ่งที่ ไม่ตัดสิน ใน session เช่น vendor หรือ deployment topology

รอบ Workshop จาก Event ก่อน Solution#

ตัวอย่าง Process Modelling สำหรับ partial refund:

1. เขียน Domain Events แบบ past tense ตาม timeline: RefundRequested, RefundApproved, ProviderRefundAccepted, WalletAdjustmentPosted
2. เติม unhappy paths: ApprovalRejected, ProviderOutcomeBecameUnknown, ReconciliationOpened
3. หา Commands/Actors: RequestRefund, ApproveRefund, SubmitProviderRefund
4. หา Policies: ใครตัดสิน approval, เมื่อ unknown ใครเริ่ม reconciliation
5. เติม Read Models/Information: approval ต้องเห็นอะไร และข้อมูลนั้นสดแค่ไหน
6. ทำเครื่องหมาย Hotspots: คำขัดแย้ง, policy ไม่มี owner, system behavior ที่ยังเดา
7. ค่อย cluster ตาม language, invariant, lifecycle และ ownership เพื่อหา boundary hypothesis

System map

Diagram นี้เป็น learning artifact ไม่ใช่ sequence ของ HTTP calls คำว่า approved ใน Approval Context และ accepted ของ provider แยกกัน เพื่อไม่ให้ระบบถือว่า approval ภายในแปลว่าเงินคืนแล้ว

Facilitation ที่เปิดเผยความไม่รู้#

ใช้กติกาเหล่านี้เพื่อให้ model มาจากคนทั้งห้อง:

• เริ่ม silent generation ให้ทุกคนเขียน event ก่อน discussion ลด anchoring จาก senior คนแรก
• เล่า timeline ซ้ายไปขวา 2 รอบ: happy path แล้ว failure/late/duplicate/manual path
• ขอ concrete example ทุกครั้งที่ได้คำว่า success, account, cancel, valid หรือ real-time
• แยก fact, policy, assumption และ question ด้วย legend ที่คนเห็นร่วมกัน
• จอด technology debate เช่น Kafka/REST/database ไว้จน semantic contract ชัด
• timebox ประเด็นที่ต้องให้ owner ภายนอกตัดสิน แทนการสร้าง consensus ปลอม
• อ่าน flow กลับจากท้ายไปต้นเพื่อหา precondition และ event ที่หาย

Incremental Notation จากผู้สร้าง EventStorming แนะนำให้เพิ่ม notation เท่าที่ผู้เข้าร่วมต้องใช้ในขณะนั้น การสอนสีและสัญลักษณ์ ทั้งหมดก่อนเริ่มเพิ่ม cognitive load และทำให้คนสนใจความถูกต้องของกระดานมากกว่าความรู้ที่ขาด

จากกระดานสู่ Artifact ที่ใช้ต่อ#

อย่าจบด้วยรูปถ่ายที่ไม่มีใครเปิดอีก ภายใน 24 ชั่วโมงให้ผู้รับผิดชอบแปลงผลเป็น:

Domain Event บนกระดานไม่เท่ากับ message ที่ต้อง publish ทุกใบ บาง event ใช้อธิบาย state change ภายใน model บาง event แปลงเป็น integration contract และบาง event เป็นเพียงคำที่ช่วยเล่าเรื่อง การตัดสิน transport, delivery guarantee และ schema เกิดภายหลัง

ทดสอบ Boundary Hypothesis ด้วย Scenario#

Cluster ที่ดูสวยต้องตอบ scenario ที่ทำให้ boundary เครียด:

1. Provider ตอบ timeout แต่ภายหลังส่ง webhook ว่าสำเร็จ
2. Customer เปลี่ยน legal name หลัง invoice ถูกออก
3. Refund request ซ้ำจาก Portal และ Customer Support
4. Policy version เปลี่ยนระหว่าง request กับ approval
5. Operations ต้องแก้รายการโดยไม่ rewrite financial history

ถามในแต่ละข้อว่า language ใดใช้, ใครตัดสิน, state ใด authoritative, transaction ใดต้อง atomic, ใครซ่อมเมื่อผลไม่แน่นอน และ context อื่นรู้ผ่าน contract อะไร หาก 1 cluster ต้องรู้ model ภายใน ของทุกกล่อง ให้ split/translation hypothesis กลับไปทบทวน

Online, Hybrid และ Asynchronous Discovery#

Remote board ช่วยทีมหลายประเทศแต่เสีย conversation bandwidth ใช้ session สั้นลง มี co-facilitator, จำกัด concurrent editors และส่ง narrative ล่วงหน้า Hybrid ที่คนบางส่วนอยู่ห้องเดียวมักสร้าง ผู้เข้าร่วมชั้น 2 จึงควรให้ทุกคนเข้าผ่าน interface เดียวหรือมี facilitator ดู remote โดยเฉพาะ

Asynchronous comment เหมาะกับ review glossary และเติม example ไม่เหมาะกับแทน workshop ทั้งหมด เพราะความขัดแย้งของคำต้องการ dialogue ให้บันทึก timezone, participant และ decision owner เพื่อไม่ให้ คำตอบจากสำนักงานใหญ่กลายเป็น universal model โดยไม่เห็น operation ในประเทศอื่น

แบบฝึกปฏิบัติ: Refund Process Workshop#

จัด session 90 นาทีด้วย scope “ Request Partial Refund ถึง Wallet Adjustment”:

0-10   Frame question, start/end, legend
10-25  Silent domain-event timeline
25-40  Walk through happy path
40-60  Add failures, duplicates, late and manual paths
60-70  Commands, policies, information and owners
70-80  Hotspots and candidate boundaries
80-90  Playback, questions, owners and next artifacts

Deliverables ต้องมี scenario 2 เส้น, glossary conflict อย่างน้อย 3 คำ, policy ที่มี owner, invariant ที่ทดสอบได้ 1 ข้อ, boundary hypothesis และคำถามที่ยังไม่ปิด ห้ามให้ “เลือก Kafka” เป็น acceptance criterion

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

• Scope เป็น business question ที่มี start/end ชัด
• ผู้เข้าร่วมมีทั้งผู้กำหนด policy และผู้รับ exception จริง
• เริ่มจาก event/failure ก่อน service/database
• Fact, policy, assumption และ question ถูกแยกกัน
• ตัวเลข financial/compliance ไม่มีการเดาใน workshop
• Cluster ถูกท้าด้วย late, duplicate, unknown และ manual scenarios
• ผลถูกแปลงเป็น glossary, test, contract และ backlog ที่มี owner
• Domain Event ไม่ถูก publish อัตโนมัติทุกใบ

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

• EventStorming Official Site — รูปแบบและเป้าหมายจากผู้สร้าง practice
• Official EventStorming Resources — starter kits และข้อจำกัดของแต่ละ format
• EventStorming Patterns — facilitation patterns และ antipatterns จากต้นทาง
• AWS Hexagonal Architecture Best Practices — first-party industry guidance ที่เชื่อม domain modelling กับ implementation