Seal Courses/Domain-Driven Design in Practice
DDD Reference

บทที่ 2 · Part 1 — Foundations and Economics

Why DDD and When It Pays

เชื่อม DDD กับ business outcome, cost of change และความเสี่ยง พร้อมรู้ว่าเมื่อใดไม่ควรลงทุนเพิ่ม

Why DDD and When It Pays

บริษัท Fintech แห่งหนึ่งใช้เวลา 3 เดือนเพิ่ม refund แบบบางส่วน แม้หน้าจอใหม่มีเพียง ไม่กี่ช่อง ปัญหาไม่ได้อยู่ที่เขียน endpoint ช้า แต่คำว่า Refund, Reversal, Void และ Credit Note หมายถึงคนละอย่างใน Product, Operations, Finance และ Engineering ทุก change จึงต้องประชุมแก้ความเข้าใจ ทดสอบซ้ำ และตามซ่อมข้อมูลที่แต่ละระบบตีความต่างกัน

DDD มีโอกาสคุ้มค่าในสถานการณ์นี้ เพราะต้นทุนหลักคือ ความซับซ้อนของความหมายและการเปลี่ยนแปลง ไม่ใช่เพราะบริษัทต้องการ folder template ใหม่ แต่หากทีมเล็กกำลังทำ CRUD หลังบ้านที่กฎนิ่ง การเพิ่ม Aggregate, Repository และ workshop ทุกสัปดาห์อาจแพงกว่าปัญหาที่มีจริง

จบบทนี้คุณจะ

เชื่อม DDD กับ business outcome และ cost of change ประเมินต้นทุนทั้งฝั่ง Business, Product, Risk, Operations และ Engineering เลือกว่าจะใช้ DDD มากน้อยเพียงใด และเขียน investment hypothesis ที่มีสัญญาณหยุดหรือขยายผลได้

[!IMPORTANT] DDD ไม่รับประกันผลตอบแทน ตารางและ score ในบทนี้เป็น Heuristic/Trade-off สำหรับตั้งสมมติฐาน ไม่ใช่สูตร ROI จากมาตรฐานสากล ผลจริงต้องวัดในบริบทบริษัท และต้องแยกผลของ DDD ออกจากการเปลี่ยนทีม, platform, process หรือ architecture ที่เกิดพร้อมกัน

สิ่งที่ธุรกิจกำลังซื้อจริง

DDD Reference วาง Ubiquitous Language, Model-Driven Design, Bounded Context และ Core Domain ไว้เป็นแกน สิ่งที่องค์กรซื้อจากการลงทุน จึงไม่ใช่ diagram แต่เป็นความสามารถ 4 ด้าน:

  1. เรียนรู้ปัญหาเร็วขึ้น — คนที่รู้ policy กับคนที่สร้างระบบตรวจ model เดียวกันได้
  2. ลดความกำกวมตอนส่งต่องาน — ชื่อใน conversation, example, contract, code และ test สื่อความหมายเดียวกันภายใน context
  3. ปกป้องกฎสำคัญ — invariant และ authoritative decision อยู่กับ owner ที่ชัด
  4. เปลี่ยนส่วนต่าง ๆ ได้อิสระขึ้น — model boundary และ contract ลดเหตุที่ change หนึ่ง ต้องลากทั้งองค์กรมา deploy พร้อมกัน

เอกสาร Domain Analysis ของ Microsoft Azure อธิบาย Strategic DDD และ Tactical DDD เป็นกระบวนการต่อเนื่องสำหรับจัดระบบรอบ business capability ไม่ใช่ขั้นตอนที่ให้คำตอบเชิงกลไก ส่วนกรณี DOMA ของ Uber แสดงปัญหาอีกระดับ: เมื่อองค์กรมี service จำนวนมาก ความเป็นอิสระที่เคยได้อาจกลายเป็น network of dependencies จึงต้องจัดกลุ่ม ownership, gateway และ dependency ใหม่ตาม domain นี่เป็น case study ของ Uber ไม่ใช่หลักฐานว่าบริษัททุกแห่งควรมี microservices หรือคัดลอก DOMA

Business Value Chain ของ DDD

คำว่า “ทำให้ business กับ tech คุยกันรู้เรื่อง” ยังวัดไม่ได้ ให้เขียน causal chain ก่อนลงทุน:

Practiceพฤติกรรมที่คาดว่าจะเปลี่ยนผลลัพธ์ใกล้ตัวBusiness outcome ที่ต้องพิสูจน์
Scenario + Ubiquitous Languageทีมถามความหมายก่อนแตก ticketrequirement churn ลดlead time ของ policy change สั้นลง
Subdomain portfolioแยกสิ่งที่ควรสร้างเองจากของทั่วไปงบและคนไปอยู่จุดสร้างความต่างtime-to-market ของ Core capability ดีขึ้น
Bounded Context + ownershipdecision มี owner และ contractcross-team handoff ลดrelease frequency เพิ่มโดย incident ไม่เพิ่ม
Aggregate + invariant testsinvalid state สร้างยากขึ้นdefect เรื่องกฎลดloss, rework และ manual correction ลด
Anti-Corruption Layervendor model หยุดที่ boundaryเปลี่ยน provider กระทบวงแคบintegration change คาดการณ์ได้ขึ้น

แถวสุดท้ายไม่ได้แปลว่าเปลี่ยน provider จะ “ง่าย” เสมอ หาก semantic capability ต่างกันมาก adapter ก็ต้องซับซ้อน คุณค่าที่หวังคือทำให้ความต่างนั้นอยู่ในจุดที่เห็นและทดสอบได้

ต้นทุนที่ต้องนับให้ครบ

DDD สร้างต้นทุนทั้งก่อนและหลัง merge:

  • เวลาของ Domain Expert, Product, Operations, Risk และ Engineer ใน modelling session
  • facilitation, preparation และการตามคำถามที่ไม่มี owner
  • การสร้างและดูแล glossary, examples, Context Map, decision record และ contracts
  • code ที่ซับซ้อนขึ้นเมื่อใช้ Entity, Aggregate, port หรือ event โดยยังไม่มีแรงรองรับ
  • migration จาก shared model/table และการรองรับ contract มากกว่า 1 version
  • cognitive load เมื่อศัพท์เฉพาะมากเกินไปหรือ boundary ละเอียดเกินทีมดูแล
  • governance และ platform ที่องค์กรใหญ่ต้องใช้เพื่อให้ autonomy ไม่กลายเป็นความกระจัดกระจาย

ดังนั้น “ใช้ DDD” ไม่ใช่ binary ทีมอาจใช้ scenario กับ Ubiquitous Language โดยยังเขียน Transaction Script ใน module เดียว หรือทำ Context Map ระดับองค์กรโดยให้ Supporting Subdomain ใช้ SaaS ไม่ต้องสร้าง Rich Domain Model

Fit Test ก่อนเริ่ม

ให้คะแนนแต่ละข้อ 0 = ต่ำ, 1 = เริ่มเห็น, 2 = สูง โดยต้องใส่หลักฐาน 1 ประโยค:

แรงคำถามที่ใช้หา evidence
Domain complexitypolicy, state transition และ exception ต้องอธิบายหลายเงื่อนไขหรือไม่
Volatilityกฎและ product proposition เปลี่ยนบ่อยเพียงใด
Ambiguityฝ่ายต่าง ๆ ใช้คำเดียวต่างความหมายจนเกิด rework หรือ incident หรือไม่
Coordination1 outcome ต้องส่งต่อหลายทีมและไม่มี owner end-to-end หรือไม่
Riskmodel ผิดทำให้เงิน, สิทธิ์, compliance หรือความเชื่อมั่นเสียหายเพียงใด
Differentiationcapability นี้สร้างข้อได้เปรียบที่บริษัทตั้งใจลงทุนเองหรือไม่
  • ผลรวม 0– 3: เริ่มจาก clear naming, examples และ simple module; ยังไม่ต้องมี DDD program
  • ผลรวม 4– 7: ใช้ lightweight discovery กับ capability ที่เจ็บจริง และตั้ง review date
  • ผลรวม 8– 12: ลงทุน Strategic DDD, policy ownership, context contracts และ Tactical DDD เฉพาะ model ที่ซับซ้อน

ช่วงคะแนนเป็น Course Convention ไม่ใช่ benchmark ความแตกต่างของ score ช่วยบังคับให้ทีม อธิบายหลักฐาน แต่ไม่ควรใช้ตัดสินแทนคน เช่น capability ที่ไม่สร้างความต่างแต่มี financial risk สูงอาจต้องลงทุนด้าน correctness และ control มาก แม้ไม่เรียกว่า Core Subdomain

ความคุ้มค่าต่อแต่ละบทบาท

บทบาทสิ่งที่ควรได้รับสัญญาณว่า DDD กลายเป็นภาระ
Business ownerเห็นว่า capability ใดสร้างความต่างและ policy ใครตัดสินworkshop ผลิตศัพท์แต่ไม่ช่วยตัดสิน portfolio
Productscenario และ exception ที่พร้อม validateทุก ticket ต้องรอ architecture committee
Risk/Compliancepolicy source, effective date และ decision boundaryengineer เดา threshold แล้วเรียกว่า domain rule
Operations/Financelifecycle, unknown state และ repair action ที่ตรงกับงานจริงhappy path สวยแต่ manual operation หายจาก model
Engineermodule, invariant, contract และ test ที่สะท้อนภาษาclass จำนวนมากแต่ change ยังกระจายเท่าเดิม
Leadershipownership และ dependency ที่จัดงบ/ทีมได้วัดจำนวน Aggregate หรือ workshop เป็นความสำเร็จ

Model ไม่ได้กำหนด Financial Policy

เพดาน refund, KYC threshold, retention และ maker-checker rule ต้องมาจาก accountable owner หรือ regulator พร้อมชื่อ เอกสาร และวันที่ DDD ช่วยทำให้ owner และตำแหน่งบังคับใช้ policy ชัดขึ้น แต่ไม่ทำให้ทีม Engineering มีอำนาจคิดค่าดังกล่าวเอง

แบบฝึกปฏิบัติ: DDD Investment Memo

เลือก capability เดียว เช่น Partial Refund และเขียน memo 1 หน้า:

Business outcome:
Observed pain and baseline:
Terms or policies currently disputed:
Capability / candidate subdomain:
Smallest DDD practices to try:
People and time cost:
Expected behavior change:
Leading evidence after 4– 6 weeks:
Business evidence after 1 quarter:
Stop / simplify / expand criteria:
Owner and review date:

ตัวอย่าง leading evidence คือจำนวน policy questions ที่ได้ owner ก่อน implementation, change set ที่ไม่ต้องแก้ข้าม module และ production correction ที่ trace กลับ scenario ได้ อย่าเลือกจำนวน sticky notes, classes หรือ microservices เพราะเป็น output ไม่ใช่ outcome

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

  • ระบุ pain ที่เกิดจริงแทนการเริ่มจากความนิยมของ pattern
  • เชื่อม practice กับพฤติกรรมและ business outcome เป็น causal chain
  • นับเวลาของ Business, Product, Operations, Risk และ Engineering เป็น cost
  • ใช้ DDD แบบไล่ระดับ ไม่บังคับ Tactical Pattern ทุกจุด
  • แยก differentiation ออกจาก operational/compliance criticality
  • มี baseline, owner, review date และเงื่อนไขหยุด
  • ไม่ใช้จำนวน artifact เป็นตัวแทนความสำเร็จ

สรุปบทนี้

DDD คุ้มเมื่อ shared understanding, model boundary และการปกป้อง invariant ลดต้นทุน ของความกำกวมและการเปลี่ยนแปลงได้มากกว่าต้นทุน modelling และ governance ทีมควรซื้อ practice ที่เล็กที่สุดซึ่งแก้ pain ที่เห็น วัดผล แล้วค่อยขยาย ไม่ต้องประกาศ transformation ทั้งบริษัทเพื่อเริ่มปรับภาษาใน 1 capability

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