Context Integration Patterns#

สองทีมอาจเชื่อมด้วย API เดียวกันแต่ relationship ต่างมาก ทีมหนึ่งร่วมออกแบบ contract ทุกสัปดาห์ อีกทีมถูก vendor เปลี่ยน schema โดยไม่มีสิทธิ์ต่อรอง และอีกคู่แชร์ model เพราะต้อง co-evolve Context Integration Patterns ตั้งชื่อทั้ง power, collaboration และ model translation ไม่ใช่เพียง protocol

Pattern ไม่ใช่ Ranking#

นิยามต้นทางอยู่ใน DDD Reference ไม่มี pattern “ดีที่สุด” ทุกแบบยอมรับ trade-off ต่างกัน

Partnership#

สอง contexts สำเร็จ/ล้มเหลวร่วมและ teams ต้อง coordinate evolution ใกล้ชิด เหมาะเมื่อ collaboration สร้าง value มากกว่าค่า coordination

บันทึก joint planning, integration tests, escalation และเวลาที่ partnership จะสิ้นสุด Partnership ถาวรระหว่าง 5 ทีมมักกลายเป็น coordination bottleneck

Shared Kernel#

แชร์ส่วน model/code/schema เล็กที่ทั้งสองฝ่ายยอม co-own ทุก change ต้อง consult กัน เหมาะเมื่อ duplication/translation แพงกว่า coordination แต่ kernel ต้องเล็กและ explicit

smell คือ package common ที่ไม่มี owner และทุกทีมเพิ่ม type ได้ Shared Kernel ไม่ใช่ utility dump

Customer/Supplier#

Upstream เป็น supplier และ downstream เป็น customer ที่มีอิทธิพลต่อ planning/contract ต้องมี negotiation channel, acceptance tests และ prioritization ไม่ใช่เรียกทุก API dependency ว่าแบบนี้

Conformist#

Downstream ยอมรับ upstream model เพราะไม่มี leverage และ translation ไม่คุ้ม เช่น internal consumer ของ stable platform Conformist เป็น conscious choice พร้อม blast radius ไม่ใช่ความล้มเหลวทางศีลธรรม

ถ้า upstream model เปลี่ยนบ่อยหรือรั่ว vendor semantics เข้า Core Domain ACL อาจคุ้มกว่า

Anti-Corruption Layer#

ACL แปล model ภายนอกให้เป็น language ของ downstream:

Provider status: succeeded
  -> ACL evaluates provider contract/version/evidence
  -> ExecutionOutcome: Accepted
  -> does not claim LedgerPosted or TransferCompleted

ACL อาจเป็น adapter/function/module ไม่จำเป็นต้องเป็น service แยก มันปกป้อง semantics แต่มี maintenance cost และต้องทดสอบ mapping/error/unknown outcomes

Open Host Service และ Published Language#

Upstream เปิด protocol ที่ออกแบบสำหรับหลาย consumers และภาษาที่ documented/versioned Published Language อาจเป็น schema/API/event catalogue หรือมาตรฐานอย่าง ISO 20022

อย่า export internal aggregate เป็น contract Contract ต้องเลือก minimum semantics, privacy, compatibility และ deprecation policy

Separate Ways#

ไม่ integrate เมื่อ value ต่ำกว่าต้นทุน เช่น 2 business units ใช้ tax provider ต่างกันและไม่มี customer journey ต้องแชร์ การ duplicate เล็กน้อยอาจลด coupling มากกว่า platform กลาง

ใช้ relationship evidence เป็น starting heuristic ได้ดังนี้:

System map

ต้นไม้นี้ไม่ใช่ ranking และ relationship เดียวอาจใช้หลาย pattern ต่อ contract จุดตัดสินจริงคือ power, semantic distance, change cadence และต้นทุน coordination/translation ที่วัดได้

เลือก Pattern ด้วย Relationship Card#

Contexts:
Business dependency:
Power / influence:
Change cadence:
Semantic distance:
Coordination cost:
Translation cost:
Current pattern and evidence:
Desired pattern:
Migration / review trigger:

ทีมคู่เดียวอาจใช้หลาย patterns ต่อ contracts ต่างกัน อย่า label relationship ทั้งหมดโดยไม่ระบุ scope

แบบฝึกปฏิบัติ: Provider Boundary#

เปรียบเทียบ 3 choices สำหรับ Payment Execution กับ provider:

1. Conformist ต่อ vendor status model
2. ACL ต่อ vendor-specific model
3. Published Language ภายในที่ adapters หลายราย map เข้า

ประเมิน multi-provider strategy, unknown outcome, versioning, team capacity, test/operations cost และสิ่งที่เปลี่ยนหากมี provider รายเดียวถาวร

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

• Pattern สะท้อน power/team relationship จริง
• Shared Kernel เล็กและมี co-ownership
• Partnership มีเวลาหรือเหตุผลจบ
• Conformist เป็น conscious cost decision
• ACL แปล semantics ไม่ใช่ rename field
• Published Language มี owner/version/deprecation
• Separate Ways ถูกพิจารณา
• Pattern มี review trigger

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

• DDD Reference — Context Map relationship patterns
• Context Mapping — team/model relationship views
• ISO 20022 Business Model — Published Language ตัวอย่างข้ามองค์กร