From Discovery to Subdomains#

หลัง workshop ทีมมักวงกลุ่ม events แล้วตั้งชื่อกล่อง Payment, Wallet, Customer ทันที แต่ cluster ตามตำแหน่งบน board ไม่ได้พิสูจน์ problem boundary Subdomain คือส่วนของ problem space ที่มี capability/knowledge coherent ส่วน Bounded Context เป็น model boundary ใน solution space บทนี้หยุดการกระโดดจาก stickies ไป services

Problem Space ก่อน Solution Space#

Subdomain ช่วยแบ่ง domain ใหญ่ตามปัญหา/ความสามารถของธุรกิจ เช่น Transfer Eligibility, Payment Execution, Funds Availability หรือ Reconciliation มันไม่ใช่ package หรือ service

Bounded Context คือ boundary ที่ model และ Ubiquitous Language ใช้ได้อย่างสอดคล้อง ความสัมพันธ์ไม่ใช่ 1 subdomain = 1 context เสมอ:

• Subdomain เดียวอาจมี legacy และ new contexts ระหว่าง migration
• context หนึ่งอาจรองรับหลาย Supporting Subdomains ที่ model เรียบง่าย
• external SaaS อาจเป็น context ของ vendor ไม่ตรง Subdomain ภายใน

Evidence สำหรับ Candidate Subdomain#

รวม 6 lenses:

Cluster ที่มีเพียง tables หรือ current team names ยังเป็น weak evidence

เสนอ Alternative Decompositions#

สำหรับ transfer เสนออย่างน้อย 2 แบบ:

แบบ A: ตาม Journey Phase

Transfer Intent -> Eligibility -> Execution -> Reconciliation

แบบ B: ตาม Authority

Customer Commitment | Risk Decision | Funds Authority | Provider Execution | Financial Records

แบบ A อ่าน flow ง่ายแต่ phase อาจปน authorities แบบ B ปกป้อง decision ownership แต่มี relationship มากขึ้น ไม่มีคำตอบจากชื่ออย่างเดียว ต้อง replay scenarios และดู policy/change coupling

System map

ลูกศรย้อนกลับคือหัวใจของ strategic discovery: diagram ไม่ได้เปลี่ยน cluster เป็น Subdomain โดยตรง แต่บังคับให้แต่ละ alternative ผ่าน scenario และ counterexample ก่อน

Cohesion และ Coupling ใน Problem Space#

High cohesion หมายถึงความรู้/rules ภายในเปลี่ยนด้วยเหตุผลสัมพันธ์กัน Low coupling หมายถึง Subdomain หนึ่งไม่ต้องรู้รายละเอียด model อีกฝ่ายเพื่อทำ outcome ของตน

ใช้ test:

• หาก provider เพิ่ม status ใหม่ Eligibility ต้องเปลี่ยนไหม
• หาก Risk policy เปลี่ยน Ledger model ต้อง deploy ไหม
• หาก customer display wording เปลี่ยน Funds decision เปลี่ยนไหม
• หาก reconciliation พบ mismatch ใครมีอำนาจแก้ fact

ถ้าทุกคำตอบคือ “ทุกส่วนเปลี่ยน” อาจมี shared model/canonical language ซ่อน coupling

Subdomain Card#

Name in Ubiquitous Language:
Business purpose and outcome:
Key scenarios:
Distinctive language:
Decisions / policies / invariants:
Knowledge and business owner:
Upstream facts required:
Downstream outcomes promised:
Core / Supporting / Generic hypothesis:
Alternative boundary:
Evidence and counterevidence:
Open questions / review date:

ชื่อควรเป็น capability ที่คนธุรกิจใช้ ไม่ใช้ technical bucket เช่น Data Service หรือ Common

Event Clusters ไม่ใช่ Event Bus Topics#

EventStorming cluster อาจบอก phase/concern แต่ orange notes ไม่บังคับให้ publish ทั้งหมด ก่อนสร้าง integration contract ต้องรู้ publisher authority, consumer need, schema/version, delivery/failure และ data classification Domain Event ภายในกับ Integration Event แยกกัน

Strategic Classification หลัง Discovery#

เมื่อ Subdomain พอชัดจึงคุย Core/Supporting/Generic กับ business strategy ไม่ให้ Engineer จัดลำพัง Classification มีผลต่อ investment ไม่พิสูจน์ architecture:

• Core อาจใช้ algorithm/model แบบ functional ไม่ต้อง Aggregate
• Supporting ที่กระทบเงินอาจต้อง rich invariant/control
• Generic ที่ซื้อ vendor ยังต้อง ACL

แบบฝึกปฏิบัติ: Decompose Transfer Domain#

ใช้ events/policies จากบทก่อนสร้าง:

1. decomposition alternatives 2 แบบ
2. Subdomain Cards อย่างน้อย 5 ใบ
3. replay scenarios 3 เรื่อง: happy transfer, indeterminate provider, reconciliation mismatch
4. coupling matrix ว่า policy change ใดแตะ Subdomain ใด
5. Core/Supporting/Generic hypotheses ภายใต้ strategy 2 แบบ

ห้ามใช้ service/database names เป็นเหตุผลหลัก และต้องระบุ 1 candidate ที่ควรรวมกับอีกส่วนกับ 1 candidate ที่อาจ split พร้อม evidence

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

• Subdomain อยู่ใน problem space และ context อยู่ใน solution space
• Candidate มาจาก capability, language, rules, lifecycle และ ownership
• มี alternative decomposition มากกว่า 1
• Scenarios ถูก replay ข้าม candidates
• Cluster ไม่ถูกเปลี่ยนเป็น topic/service อัตโนมัติ
• Strategic type มี business owner และ review trigger
• Uncertainty/counterevidence ถูกเก็บไว้

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

• DDD Reference — Domain, Core Domain และ Bounded Context
• DDD Starter Modelling Process — Decompose และ Strategize
• Core Domain Charts — strategic classification