Core, Supporting and Generic Subdomains#

บริษัท Fintech อาจเรียกทุกระบบที่แตะเงินว่า “core” แล้วสรุปว่าต้องสร้างเองด้วย architecture ซับซ้อนที่สุด ผลคือทีมใช้เวลาออกแบบ Notification และ Tax library เท่ากับการพัฒนา pricing หรือ risk decision ที่สร้างความแตกต่างจริง ขณะเดียวกันระบบ Generic ที่ซื้อมาอาจมี operational risk สูงมากจนถูกมองข้ามเพราะ “ไม่ใช่ Core”

การจำแนกตอบคำถามเชิงกลยุทธ์#

ใน DDD คำว่า Subdomain คือส่วนของ problem space ส่วน classification ช่วยตัดสินว่า องค์กรควรสร้างความได้เปรียบที่ไหน ตาม Learning Domain-Driven Design ความหมายใช้งานได้ดังนี้:

• Core Subdomain สร้างหรือรักษาความได้เปรียบของธุรกิจและต้องเปลี่ยนตาม strategy
• Supporting Subdomain จำเป็นต่อธุรกิจแต่ไม่ได้เป็นแหล่งความแตกต่างหลัก มักมี logic เฉพาะองค์กรที่ซื้อสำเร็จรูปได้ไม่ตรงทั้งหมด
• Generic Subdomain เป็นปัญหาที่หลายองค์กรแก้คล้ายกันและมี product/library/service ที่ซื้อหรือใช้ซ้ำได้

classification เป็นการเปรียบเทียบกับ strategy ปัจจุบัน ไม่ใช่คุณสมบัติติดตัวตลอดไป Fraud decision อาจเป็น Core สำหรับบริษัทที่แข่งด้วย approval rate แต่เป็น Supporting สำหรับอีกบริษัทซึ่งใช้ provider ภายนอกและแข่งขันด้าน merchant experience

อย่าจำแนกจากชื่อ technology หรือความยากของ algorithm ระบบ OAuth/OIDC ซับซ้อนแต่ มักเป็น Generic ในเชิง strategy ส่วนกฎคำนวณ fee ที่มี if ไม่กี่บรรทัดอาจเป็น Core หากเป็นกลไก pricing ที่คู่แข่งลอกได้ยากและเปลี่ยนบ่อย

Core ไม่เท่ากับ Criticality#

ใช้ 2 แกนแยกกันเสมอ:

Core ตอบว่า “เราชนะด้วยอะไร” ส่วน criticality ตอบว่า “ถ้าผิด เสียหายเพียงใด” Generic authentication ยังต้องมี security engineering, availability, incident response และ accountable ownership สูง การซื้อ identity provider ไม่ได้ outsource ความรับผิดชอบ เรื่อง configuration, tenant isolation หรือ use-case authorization

สร้าง ซื้อ ใช้ SaaS หรือจ้างบริษัทภายนอก#

classification ช่วยตั้งต้นการตัดสินใจ แต่คำตอบจริงต้องดู switching cost, data sensitivity, integration volatility, market maturity และความสามารถทีม:

Payment Provider Integration มักเป็น Supporting หรือ Generic integration capability แต่ provider selection/routing อาจกลายเป็น Core หากองค์กรชนะด้วย conversion, cost และ resilience ข้ามหลาย provider ดังนั้นห้ามใช้คำว่า payment แล้วสรุปชนิดเดียวทั้งก้อน

Tax Calculation เป็นตัวอย่างที่น่าสนใจ หากขายในประเทศเดียวและซื้อ engine มาตรฐานได้ อาจเป็น Generic แต่ถ้าบริษัทมี product ข้ามประเทศซึ่ง tax treatment เป็นส่วนสำคัญของ offering มันอาจเป็น Supporting ที่มี model เฉพาะ หรือ Core ใน strategy ช่วงหนึ่ง

จำแนก Capability ไม่ใช่ Application#

Application หนึ่งมีหลาย Subdomain ได้ Wallet product อาจประกอบด้วย:

• Account lifecycle และ balance availability policy
• Ledger recording และ correction workflow
• Transfer orchestration
• Notification delivery
• Identity integration
• Reconciliation operations

การติดป้าย Wallet ทั้งก้อนว่า Core ทำให้ตัดสินใจหยาบเกินไป ให้แตกเป็น capability ที่มี language, rule และ outcome ชัดก่อน แล้วจำแนกพร้อมเหตุผล เช่น Available Balance Policy อาจ Core ขณะที่ SMS Delivery Generic

ใช้ evidence 4 ประเภท:

1. ผู้บริหารระบุความแตกต่างของ product และ metric ที่ต้องชนะ
2. Domain experts มีความรู้เฉพาะที่ vendor ทั่วไปไม่มี
3. กฎเปลี่ยนตาม experiment หรือ strategy บ่อย
4. การเลียนแบบ capability ทำให้คู่แข่งลดความต่างได้จริง

จำนวน engineer หรือจำนวน table ไม่ใช่ evidence ของ Core บาง legacy module ใหญ่มาก เพราะสะสม accidental complexity แต่ไม่ได้สร้าง advantage

แบบฝึกปฏิบัติ: Subdomain Portfolio#

สร้างตารางสำหรับ Ledger, Notification, Tax Calculation และ Payment Provider Integration:

Capability:
Candidate type: Core | Supporting | Generic | Unknown
Strategic evidence:
Criticality: Low | Medium | High
Security/compliance owner:
Build/buy starting posture:
What could change the classification:
Review date:

ตัวอย่างคำตอบที่ซื่อสัตย์:

Capability: Provider Routing
Candidate type: Unknown, possibly Core
Strategic evidence: Product claims higher acceptance, but no measured comparison yet
Criticality: High
Owner: Head of Payments; architecture review dated 2026-08-08
Starting posture: keep application-owned routing policy, buy provider connectivity
Revisit when: approval-rate and cost data are available

คะแนนแบบฝึกหัด:

• ผ่าน เมื่อทุก capability มี evidence และ criticality แยกจาก type
• ดี เมื่อมี Unknown, review signal และ build/buy caveat
• ควรทำใหม่ เมื่อทุกอย่างเป็น Core หรือ classification อ้างเพียงว่าแตะเงิน/โค้ดยาก

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

• จำแนก capability ไม่ใช่ชื่อ product หรือ repository
• Core มี strategic evidence มากกว่าความรู้สึกว่าสำคัญ
• Criticality, security และ compliance อยู่คนละแกน
• Generic dependency ยังมี owner, exit plan และ operational controls
• Build/buy decision พิจารณา lock-in และ data responsibility
• Classification มีวันที่และ trigger สำหรับทบทวน

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

• Learning Domain-Driven Design, Chapter 1 — Core, Supporting และ Generic Subdomains
• DDD Reference — Core Domain และ strategic patterns
• Learning Domain-Driven Design closing comparison — เปรียบเทียบแนวทางลงทุนตามชนิด Subdomain