Context Mapping Relationships#

การวาด Risk → Transfer → Ledger แสดงลำดับ แต่ไม่บอกว่าใครกำหนด contract, ใครรอใคร, ฝ่ายใดยอมรับ model ของอีกฝ่าย หรือใครซ่อมเมื่อ message หาย Context Map ทำให้ relationship, power และ translation strategy เป็นสิ่งที่องค์กรพูดคุยและเปลี่ยนได้

Map ไม่ใช่ Landscape Inventory#

Context Map ใน DDD Reference อธิบาย Bounded Contexts และ relationships ระหว่างกัน กล่องอย่างเดียวไม่พอ แต่ละ edge ต้องตอบ:

Upstream / downstream:
Business and technical owners:
Relationship pattern:
Commands, events or queries:
Published Language / schema owner:
Translation point:
Identity / correlation:
Consistency / freshness:
Failure and recovery owner:
Version / deprecation expectation:

Upstream และ Downstream#

Upstream มีอิทธิพลต่อ model/contract ที่ downstream ต้องรับ แต่ไม่ได้แปลว่า call direction เสมอ Ledger อาจ publish EntriesPosted ให้ Portal ขณะที่ Portal เป็นผู้เรียก query แต่ Ledger ยังเป็น upstream ของ financial semantics

ถาม power:

• downstream มีช่องทางขอ change หรือไม่
• upstream optimize เพื่อ consumer รายเดียวหรือหลายราย
• contract breaking change มี negotiation/deprecation อย่างไร
• consumer ถูกบังคับ conform หรือมี ACL

Map หลายมุมดีกว่า Giant Map#

DDD Crew Context Mapping แนะนำ map ที่ตอบ คำถามเฉพาะ เช่น:

• Model propagation map: concepts/meaning ไหลอย่างไร
• Team influence map: ฝ่ายใดมี power/communication แบบใด
• Data authority map: ใครเป็น source of truth และ snapshot อยู่ที่ไหน
• Journey map: command/event/query สำหรับ scenario หนึ่ง

Giant enterprise map มักเก่าเร็วและลูกศรไม่บอก semantics เริ่มจาก Transfer under unknown provider outcome แล้วรวมเฉพาะ contexts ที่เกี่ยว

As-Is กับ To-Be#

As-Is ต้องซื่อสัตย์:

Portal reads Wallet tables directly
Risk sends CSV nightly
Transfer copies Provider statuses verbatim
Operations reconciles in spreadsheet

To-Be อาจเสนอ ACL, Published Language หรือ command ownership แต่ต้องมี migration step ห้าม redraw desired lines แล้วลบ operational responsibility ของของเก่า

Trace Journey บน Map#

System map

ลูกศรเป็น hypothesis ของ semantic contract ไม่ใช่ topology ให้ใส่ owner และ unknown path ใน artifact จริง หาก Payment timeout Transfer ต้องรู้ว่า Reconciliation รับ responsibility เมื่อใด

Measure Relationship Cost#

เก็บ evidence:

• coordination hours ต่อ contract change
• coordinated deployment percentage
• breaking changes/incidents จาก semantic mismatch
• wait time เพื่อขอ upstream change
• duplicated translation logic
• manual reconciliation backlog

Metric ช่วยตัดสินว่าควรเปลี่ยน relationship ไม่ใช่บอกว่า dependency ทุกเส้นผิด

แบบฝึกปฏิบัติ: 2 Maps of One Journey#

ทำ map 2 ใบสำหรับ Provider Outcome Became Indeterminate:

1. model propagation/translation map
2. team influence/failure ownership map

ต้องใส่ As-Is/To-Be, owner ทุก edge, stable identity, recovery path และ 1 relationship ที่ตั้งใจ คงไว้แม้มี coupling เพราะ cost ของการแยกสูงกว่า

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

• Map มี relationship semantics ไม่ใช่กล่อง/ลูกศรลอย ๆ
• Upstream/downstream แยกจาก call direction
• Map ตอบ decision question เฉพาะ
• As-Is ไม่ถูกแต่งให้เหมือน To-Be
• Data flow แยกจาก decision authority
• Failure/recovery และ version owner อยู่บน edge
• มี evidence ของ relationship cost

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

• DDD Reference — Context Map patterns
• DDD Crew Context Mapping — collaborative maps หลายมุม
• DORA Loosely Coupled Teams — coordination/deployment signals