Business Domains, Subdomains and Domain Experts#

ทีมหนึ่งได้รับโจทย์ว่า “ทำ cross-border transfer ให้สำเร็จมากขึ้น” แล้วเริ่มวาด Payment Service, Ledger Service และ Risk Service ทันที แต่ Product หมายถึงเลือก provider ให้เหมาะกับ customer promise, Operations หมายถึงลดรายการที่ค้างโดยไม่รู้ผล ส่วน Finance หมายถึงพิสูจน์ยอดและแก้ mismatch ได้ ชื่อ project เดียวจึงซ่อนปัญหาธุรกิจหลายแบบ ถ้ายังไม่รู้ว่าบริษัทแข่งขันด้วยอะไร ใครรู้กฎจริง และ กิจกรรมใดร่วมกันสร้างผลลัพธ์ การเลือก service, database หรือ pattern ก็ยังไม่มีฐานให้ตัดสิน

Software เริ่มจากบริษัทกำลังพยายามทำอะไร#

Engineer ไม่จำเป็นต้องบริหารบริษัท แต่ต้องเข้าใจบริบทที่ทำให้ software มีเหตุผลจะถูกสร้าง Requirement อย่าง “เพิ่ม success rate”, “ลด fraud” หรือ “ปิด settlement เร็วขึ้น” ไม่ใช่เพียง feature list แต่เป็นส่วนหนึ่งของ strategy, customer promise และ operating model

ถ้าไม่เห็นบริบทนี้ ทีมอาจ optimize สิ่งที่วัดง่ายแต่ไม่สร้างคุณค่า เช่นลด latency ของหน้าจอ ขณะที่ต้นทุนจริงมาจาก provider outcome ที่คลุมเครือ หรือสร้าง workflow อนุมัติที่เร็วขึ้นโดยไม่รู้ว่า policy owner ต้องการ evidence อะไร DDD จึงเริ่มจาก problem space ของธุรกิจ ก่อน solution space ของ code และ infrastructure

คำถามเปิดที่ใช้ได้กับทุกบริษัทคือ:

1. บริษัทให้ผลลัพธ์อะไรแก่ลูกค้าหรือผู้รับบริการ
2. บริษัทแข่งขันหรือสร้างความแตกต่างด้วยอะไร
3. กิจกรรมทางธุรกิจใดต้องร่วมกันจึงส่งมอบผลลัพธ์นั้นได้
4. ใครมีความรู้และอำนาจตัดสินกฎของแต่ละกิจกรรม
5. Software ส่วนที่เรากำลังสร้างช่วยกิจกรรมใด และจงใจไม่รับผิดชอบอะไร

Business Domain คือพื้นที่กิจกรรมหลักของธุรกิจ#

Business Domain คือพื้นที่ปัญหาและกิจกรรมหลักที่องค์กรดำเนินการเพื่อส่งมอบคุณค่า เช่น ประกันภัย, marketplace, payroll processing หรือ international money transfer ไม่ใช่ชื่อ repository, application หรือ department

บริษัทหนึ่งอาจทำงานในหลาย Business Domains ตัวอย่างเช่นบริษัท Fintech อาจให้ทั้ง money transfer, merchant acquiring และ lending แต่ละ domain มีลูกค้า, economics, regulation, language และ competitive strategy ต่างกัน และสามารถเปลี่ยนตามเวลาเมื่อบริษัทเข้าสู่ตลาดหรือเลิกผลิตภัณฑ์

ในคอร์สนี้ Running Case ใช้ Business Domain ว่า multi-provider money transfer ภายใต้ customer promise เรื่องความโปร่งใสและความน่าเชื่อถือ การระบุ domain เช่นนี้ยังไม่บอกว่า software ต้องเป็น monolith หรือ microservices มันเพียงกำหนดสนามที่เรากำลังเรียนรู้

Subdomain คือส่วนของงานธุรกิจที่ร่วมกันสร้างผลลัพธ์#

Business Domain ใหญ่เกินกว่าจะอธิบายด้วย model เดียว องค์กรต้องทำกิจกรรมหลายชุดร่วมกัน Subdomain คือพื้นที่กิจกรรมทางธุรกิจที่มี purpose, knowledge และความสามารถสัมพันธ์กัน ทุก Subdomain เป็น building block ของ Business Domain แต่ไม่มี Subdomain เดียวอธิบายบริษัททั้งหมด

System map

ภาพนี้เป็น problem-space decomposition ชื่อกล่องยังไม่ใช่ Bounded Context, team, service หรือ database และลูกศรไม่ได้แทน network call รายชื่อเป็นจุดเริ่มสนทนาที่ต้องทดสอบด้วย scenario, language, policy, lifecycle, ownership และ change pattern ในบทต่อไป

ใช้ตารางนี้แยกคำที่มักปนกัน:

Subdomain มีคุณค่าทางกลยุทธ์ต่างกัน#

DDD ใช้การจัดประเภทเพื่อเลือกว่าจะลงทุนเรียนรู้ สร้าง ซื้อ หรือใช้ solution พอดีอย่างไร

คำว่า Core Domain ใช้แพร่หลายใน DDD เพื่อเรียก Subdomain ที่เป็น strategic differentiator ไม่ได้หมายความว่ามันครอบทั้ง Business Domain และไม่ได้บอกว่าต้องเป็น service กลางของระบบ

การจัดประเภทขึ้นกับ strategy และเปลี่ยนได้ Provider Routing อาจเป็น Core Domain เมื่อบริษัทแข่งขัน ด้วย success rate/cost ของการเลือก rail แต่เป็น Supporting Subdomain เมื่อบริษัทใช้ provider เดียว ตาม contract ที่ตายตัว Authentication มักเป็น Generic Subdomain เพราะมี solution ที่ตลาดพิสูจน์แล้ว แต่ยังมีความซับซ้อนและผลกระทบด้าน security สูง

Core Domain อาจไม่ได้อยู่ใน Software#

ความได้เปรียบของบริษัทอาจมาจากงานของคน, supply chain, brand, physical process หรือ proprietary knowledge ไม่จำเป็นต้องเป็น algorithm ตัวอย่างบริษัทตรวจ fraud แบบ manual อาจมี Core Domain คือ วิธีที่ analyst อ่านหลักฐานและสร้าง judgment ส่วน application ที่แสดงเอกสารอาจเป็น Supporting Subdomain หากเพียงจัดคิวและบันทึก comment

Software ยังสำคัญต่อ flow แต่การเรียกทุกระบบที่สำคัญว่า Core ทำให้งบและ talent กระจายผิดจุด ให้ถามว่า “ลูกค้าหรือ economics จะเสียความแตกต่างอะไร หากคู่แข่งทำส่วนนี้ได้เหมือนเรา” แล้วแยกจาก คำถามว่า “ระบบหยุดแล้วกระทบมากเพียงใด”

Domain Experts คือแหล่งความรู้และอำนาจตามขอบเขต#

Domain Expert คือผู้เชี่ยวชาญในงานธุรกิจที่เรากำลัง model และเป็นแหล่งความรู้เรื่อง language, rules, exceptions และผลลัพธ์ ไม่จำเป็นต้องมีตำแหน่งคำว่า Expert และไม่ใช่ Engineer หรือ Business Analyst โดยอัตโนมัติ

Domain Expert ใน Money Transfer อาจมีหลายคน:

• Product owner อธิบาย customer promise และ strategy
• Operations specialist รู้ late callback, manual repair และ exception ที่เกิดจริง
• Risk/Compliance owner มีอำนาจยืนยัน policy พร้อม source, jurisdiction และ effective date
• Finance/Accounting owner นิยาม financial facts, posting และ correction
• Customer Support รู้คำที่ลูกค้าใช้และ pain ที่ dashboard ไม่บอก
• Treasury/Settlement specialist รู้ cash movement และ mismatch กับ counterparties

System map

ไม่มีคนใดรู้ทุก Subdomain และ consensus ไม่ได้แทน authority หาก Operations บอกพฤติกรรมจริงขัดกับ policy document ทีมต้องเก็บ contradiction และส่งให้ accountable owner ตัดสิน ไม่ให้เสียงที่ดังที่สุด ใน workshop ปิดคำถาม

หา Subdomain จากงานจริง ไม่ใช่จาก Org Chart#

Department เป็นจุดเริ่มที่มีประโยชน์แต่หยาบเกินไป Customer Operations หนึ่งฝ่ายอาจทำทั้ง case intake, evidence collection, provider escalation และ financial correction ซึ่งใช้ language, authority และ skill ต่างกัน ในทางกลับกัน use case เดียวอาจข้ามหลาย departments

ขั้นตอนเริ่มต้น:

1. ระบุ customer/business outcome และ start/end ของ scenario
2. เขียน activities, decisions, events และ work objects ที่เกิดจริง
3. cluster งานที่ใช้ language, rules, lifecycle และ knowledge ใกล้กัน
4. หา change pattern ว่า requirement ใดเปลี่ยนพร้อมกันและเพราะเหตุผลเดียวกัน
5. ระบุ Domain Experts และ decision authority ของแต่ละ cluster
6. เสนอ decomposition มากกว่า 1 แบบแล้ว replay happy, rejection, late และ unknown paths
7. หยุดแตกเมื่อส่วนย่อยยังเป็นชุด coherent use cases และการแตกต่อไม่เปลี่ยน strategic decision

Subdomain ที่ coherent มักมี use cases ซึ่งเกี่ยวข้องกับ actors, business concepts, rules และ lifecycle เดียวกัน แต่การใช้ table ชุดเดียวไม่พอพิสูจน์ cohesion โดยเฉพาะ legacy database ที่หลายงานเขียนร่วมกัน

Core Domain ควรถูก distill ลึกพอให้แยก Generic/Supporting work ออกและทำให้ investment โฟกัส ส่วน Generic หรือ Supporting อาจหยุดที่ขอบเขตกว้างกว่า หากการแตกต่อไม่ให้ข้อมูลที่ช่วย build/buy/ partner หรือ ownership decision

Worked Example: Money Transfer Strategy#

สมมติบริษัทแข่งขันด้วย transparent multi-provider routing: ลูกค้าต้องเห็นค่าธรรมเนียมและสถานะ ที่ซื่อสัตย์ บริษัทเลือก provider/rail เพื่อเพิ่ม reliability และจัดการ unknown outcome ได้ดีกว่าคู่แข่ง

ตารางนี้ไม่ใช่ Fintech blueprint หาก strategy เปลี่ยนเป็น white-label transfer ผ่าน provider เดียว Routing อาจไม่ใช่ Core Domain ขณะที่ merchant onboarding หรือ integration experience กลายเป็นจุดลงทุน ทีมต้องเขียนเหตุผลและ review trigger ไม่ใช่จำ classification จากชื่อ capability

แบบฝึกปฏิบัติ: วิเคราะห์ Payout Platform#

บริษัทให้ merchant ส่ง payout ไปยังผู้รับจำนวนมาก ปัจจุบันแข่งขันด้วย onboarding ที่เร็วและรายงาน สถานะที่อธิบายได้ ใช้ provider ภายนอกสำหรับ execution แต่ Operations ต้อง reconcile รายการที่ provider ตอบช้าหรือส่ง report ไม่ตรง

ให้ทำงาน 4 ขั้น:

1. เขียน Business Domain และ customer promise เป็น 1 ประโยค
2. ระบุ Subdomains อย่างน้อย 6 ส่วน โดยไม่ใช้ชื่อ service/database
3. จัด Core Domain, Supporting และ Generic พร้อม evidence 1 ข้อต่อแถว
4. เปลี่ยน strategy เป็น “แข่งขันด้วย lowest-cost dynamic routing” แล้วระบุ classification ที่เปลี่ยน

คำตอบที่ดีไม่จำเป็นต้องเหมือนกัน แต่ต้องแยก differentiation จาก criticality ระบุสิ่งที่ยังไม่รู้และ บอก Domain Expert ที่ต้องตอบ เช่น Treasury, Payout Operations, Compliance หรือ Finance

ความเข้าใจผิดที่ควรจับตั้งแต่ต้น#

• Business Domain = application: application เป็น solution; domain คือพื้นที่กิจกรรม/ปัญหา
• Subdomain = microservice: Subdomain อยู่ใน problem space; service เป็น deployment choice
• Core = ทุกอย่างที่สำคัญ: criticality และ differentiation เป็นคนละแกน
• Generic = ง่าย: solved/available ไม่ได้แปลว่า technical implementation ง่าย
• Supporting = เขียนลวกได้: rigor ต้องตาม failure impact, security และ control
• Domain Expert = manager คนเดียว: expertise และ authority มี scope และกระจายหลายบทบาท
• Classification ถาวร: strategy, market และ capability เปลี่ยน การจัดประเภทจึงต้อง review

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

• อธิบาย Business Domain ด้วย customer/business outcome ได้
• Subdomain เป็น business activity ไม่ใช่ชื่อ software component
• ระบุ Core Domain จาก differentiation ของ strategy ปัจจุบัน
• ไม่ใช้ Generic/Supporting เป็นข้ออ้างลด correctness หรือ security
• แยก software Core จากความได้เปรียบที่อยู่ในงานของคนหรือ physical process
• ระบุ Domain Experts ตาม knowledge และ decision authority
• หา boundary จาก coherent use cases, language, rules, lifecycle และ change pattern
• มี alternative decomposition และ scenario สำหรับทดสอบ

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

• Learning Domain-Driven Design, Chapter 1 — Business Domain, Subdomains และ Domain Experts
• DDD Reference — Core Domain, Generic Subdomain และ strategic design vocabulary
• Azure Domain Analysis — domain analysis, Subdomains และ Bounded Contexts
• Core Domain Charts — collaborative analysis ของ differentiation และ model complexity ตามเวลา