Bounded Context Canvas#

กล่องชื่อ Payments บน Context Map ดูชัดจนถามว่า payments ไหน ใครมีอำนาจตัดสิน success หรือ context รับผิดชอบ provider connectivity, customer intent, ledger posting ทั้งหมดหรือไม่ Bounded Context Canvas ช่วยให้ boundary hypothesis ถูกตรวจผ่าน purpose, language, decisions, messages, assumptions และ ownership แทนการอาศัยชื่อกล่อง

Canvas มีไว้สนทนา#

DDD Crew Bounded Context Canvas เป็น collaborative tool สำหรับอธิบาย context ให้หลายมุมมองตรวจ ไม่ใช่ certificate ว่า boundary ถูก ใช้ canvas หลังมี discovery evidence พอ ไม่เริ่มด้วยกรอก template จาก service list

ส่วนที่ 1: Name และ Purpose#

ชื่อสะท้อน language เช่น Payment Execution ชัดกว่า Payments Service

Purpose:
Execute provider-facing payment attempts and establish execution outcomes

In scope:
- provider attempt lifecycle
- provider identifiers and outcome reconciliation

Out of scope:
- customer eligibility policy
- ledger posting rules
- customer-facing balance

Purpose เป็น outcome/decision ไม่ใช่รายการ endpoints

ส่วนที่ 2: Strategic Classification#

ระบุ Core/Supporting/Generic hypothesis พร้อม reason, business owner และ review trigger อย่า map type ไป architecture เช่น Supporting ไม่ได้แปลว่า CRUD และ Core ไม่ได้แปลว่า microservice

เพิ่ม criticality/risk แยก:

Strategic type: Supporting under current provider strategy
Operational criticality: High
Financial/compliance risk: Owner assessment required
Review when: multi-provider routing becomes differentiator

ส่วนที่ 3: Business Decisions#

Canvas ต้องบอก context ตัดสินอะไร:

• attempt ใหม่สร้างได้เมื่อใด
• outcome ใด known vs indeterminate
• callback ผูกกับ attempt ใด
• duplicate evidence เปลี่ยน state ได้หรือไม่

ถ้ารายการมี “คำนวณ available funds” แต่อำนาจอยู่ Wallet ต้องย้ายหรือระบุ upstream fact

ส่วนที่ 4: Ubiquitous Language#

เก็บ terms พร้อม statements/counterexamples:

หาก glossary มีคำจาก upstream/vendor ให้ label ว่า external language และ translation

ส่วนที่ 5: Communication#

Inbound/outbound แยก command, event, query:

Inbound command: Execute Transfer
Inbound fact: Funds Reservation Confirmed
Outbound event: Execution Outcome Established
Outbound query: none for financial decision

ระบุ owner/schema/version/failure expectation แต่ไม่ต้องเลือกระหว่าง REST/message ใน canvas แรก

ส่วนที่ 6: Assumptions และ Verification#

เขียนสิ่งที่อาจผิด:

• provider reference unique ต่อ merchant account
• callback order ไม่จำเป็นต่อ outcome
• one team can own all provider adapters
• execution context need not decide customer eligibility

แต่ละ assumption มี verification เช่น contract test, event data sample, owner interview, change-history analysis หรือ production metric

Canvas Review#

ให้ reviewers 5 บทบาท:

Review ไม่ใช่ central architecture approval Context owner แก้ canvas เมื่อ model เปลี่ยนและแจ้ง consumers ตาม contract governance

แบบฝึกปฏิบัติ: Payment Execution Canvas#

กรอก canvas 1 ใบพร้อม:

• purpose/in/out
• strategic type + risk axes
• business decisions 5 ข้อ
• language 8 terms พร้อม 3 counterexamples
• inbound/outbound contracts
• assumptions 5 ข้อและ verification
• owners/review date
• alternative boundary ที่รวม Reconciliation และ trade-off

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

• Canvas เริ่มจาก discovery evidence
• Purpose เป็น business outcome/decision
• In/out of scope ชัด
• Strategic type แยกจาก criticality/risk
• Language มี examples/counterexamples
• Communication ระบุ semantics/failure
• Assumption มี verification และ owner
• Canvas เปลี่ยนได้ ไม่เป็น phase gate

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

• Bounded Context Canvas — template และ guidance จาก DDD Crew
• DDD Starter Modelling Process — Define activity
• DDD Reference — Bounded Context และ relationship patterns