Capstone: Money Transfer under Change#

บริษัท AcmeTransfer ให้บริการ domestic และ cross-border transfer ผ่านหลาย provider Strategy ใหม่ ต้องเพิ่ม provider รายที่ 2, รองรับ jurisdiction ใหม่ และลดเวลาซ่อมรายการที่ outcome ไม่แน่นอน โดยไม่ให้ customer ถูก debit ซ้ำ Capstone นี้ไม่ได้ให้ architecture สำเร็จรูป แต่บังคับให้ผู้เรียน เดินครบวงรอบ business → discovery → strategy → boundaries → model → process → adoption evidence

Scenario Base#

Customer สร้าง Transfer Intent พร้อม Money/Beneficiary ระบบประเมิน eligibility ภายใต้ policy version ที่มี owner reserve funds ส่ง provider รับ asynchronous outcome post financial records แสดง status/balance และ reconcile กับ settlement report

Failure ที่ต้องรองรับ:

• request ซ้ำ
• policy หมดอายุระหว่าง intent กับ execution
• provider timeout หลังรับ request
• webhook ซ้ำ/ไม่เรียง
• reservation release ชนกับ late success
• posting สำเร็จแต่ display lag
• settlement mismatch พบวันถัดไป
• Operations correction ต้องมี approval/evidence

Phase 1: Business and Economics#

ส่ง:

Business strategy and customer outcome:
Observed pain / baseline:
Why custom domain knowledge matters:
DDD practices to try and their cost:
Stop / simplify / expand criteria:
Owner and review date:

แยก differentiation, domain complexity, criticality และ compliance risk

Phase 2: Collaborative Discovery#

1. Big Picture EventStorming timeline + pivotal events/hotspots
2. Domain Storytelling ของ Customer happy path และ Operations reconciliation
3. Example Map ของ Cancel Indeterminate Transfer
4. glossary conflicts อย่างน้อย 8 คำ
5. questions พร้อม named owners

Board ไม่ใช่ final design ต้องสรุป learnings/unknowns

Phase 3: Strategic DDD#

ส่ง:

• Subdomain alternatives 2 แบบ
• Core/Supporting/Generic classification ภายใต้ strategy ปัจจุบันและ strategy เปลี่ยน
• Bounded Context hypotheses พร้อม merge/split alternatives
• Context Maps 2 มุม: model propagation และ team/authority
• Bounded Context Canvas ของ Payment Execution หรือ Funds Authority
• integration patterns ต่อ edge พร้อมเหตุผล

ห้ามสูตร 1 Subdomain = 1 Context = 1 Service

Phase 4: Tactical Model#

เลือก Transfer Intent หรือ Funds Reservation:

Scenario and Ubiquitous Language:
Entities / identities:
Value Objects:
Aggregate / invariants:
Policies / provenance:
Domain Service / Specification, if justified:
Factory / Repository, if justified:
Domain Events:
Patterns deliberately omitted:
Concurrency strategy:

มี Go probe และ executable examples แต่คะแนนมาจาก model reasoning ไม่ใช่จำนวน files

Phase 5: Running Process#

ส่ง Domain Message Flow:

System map

เพิ่ม:

• application commands/results
• ACL mapping provider A/B
• Published Language version
• transaction/outbox/inbox boundaries
• idempotency identities
• crash matrix อย่างน้อย 8 จุด
• compensation/forward recovery
• reconciliation/human task owner
• display freshness และ forbidden decision

Acceptance: replay failures ไม่สร้าง provider/financial effect ซ้ำ และ unknown ไม่ถูก map failed

Phase 6: Surprise Changes#

หลัง proposal แรก ให้รับ changes:

1. provider B ไม่มี idempotency contract เหมือน A
2. Risk policy decision validity สั้นลงตาม owner-approved version
3. Corporate acquisition เพิ่ม legacy Ledger ที่เปลี่ยนไม่ได้ 18 เดือน
4. Customer ต้องเห็น transfer รวมจากหลาย entities

ผู้เรียนต้อง revise language, context relationships, ACL/process และ ADR ไม่เพียงเพิ่ม adapters ระบุ model hypothesis เดิมที่ถูกหักล้าง

Phase 7: 3 Company Contexts#

ทุก variant ต้องบอก practices included/omitted, accepted cost, baseline และ review trigger

Evaluation Rubric#

สัดส่วนเป็น Course Convention ไม่ใช่มาตรฐาน DDD ให้คะแนน 0 missing / 1 assumed / 2 evidenced

Final Review Questions#

• Domain Expert ใช้ language/model เล่า failure ได้หรือไม่
• boundary alternative ถูกพิจารณาหรือแค่ตาม org/service เดิม
• policy ทุกตัวมี authority/provenance หรือ question owner
• model ทำ invalid financial state ยากขึ้นอย่างไร
• display/decision paths แยกหรือไม่
• company context ทำให้ practice เปลี่ยนอย่างมีเหตุผลหรือไม่
• metric พิสูจน์ payoff ไม่ใช่นับ artifacts หรือไม่
• model อะไรจะทบทวนเมื่อ strategy/evidence เปลี่ยน

รายการตรวจสอบสุดท้าย#

• เริ่มจาก business outcome และ cost
• discovery มีหลาย perspectives/failures
• language bounded และใช้จริง
• Strategic/Tactical DDD เชื่อมแต่ไม่ปน
• Context ไม่เท่ากับ service/team/database
• Tactical patterns เลือกจาก forces
• external language ถูกแปล
• unknown/reconciliation เป็น domain concepts
• policy provenance ครบ
• company variants และ measurement ชัด

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

• DDD Reference — vocabulary authority
• DDD Starter Modelling Process — iterative end-to-end flow
• SAP DDD Kata — first-party practice kata
• Azure Domain Analysis — current guidance