Complexity and Core Domain Strategy#

บริษัทหนึ่งใช้ engineer ที่เก่งที่สุดสร้าง Notification system ใหม่ ขณะที่ Pricing policy ซึ่งสร้าง รายได้และเปลี่ยนทุกสัปดาห์อยู่ใน spreadsheet ที่มีคนเดียวเข้าใจ ทั้งสองระบบสำคัญ แต่ความสำคัญ คนละแกน DDD ช่วยให้ธุรกิจลงทุน modelling และ talent ในจุดที่สร้างความแตกต่าง โดยไม่สรุปว่า สิ่งที่ critical ทุกอย่างคือ Core Domain

Complexity ที่ DDD สนใจ#

DDD ให้ leverage สูงเมื่อ complexity อยู่ในความรู้และกฎของธุรกิจ:

• policy หลายชุดโต้ตอบกัน
• state/lifecycle มี alternate และ exception paths
• คำเดียวกันมีหลายความหมายตาม context
• decision ต้องใช้ temporal facts หรือ policy version
• change หนึ่งกระทบหลายฝ่ายเพราะ ownership ไม่ชัด
• ความผิดพลาดทำให้เงิน สิทธิ์ หรือความเชื่อมั่นเสียหาย

Technical complexity เช่น throughput, encryption, consensus หรือ rendering สำคัญเช่นกัน แต่ Tactical DDD อาจไม่ใช่เครื่องมือหลัก Algorithm ซับซ้อนอาจเป็น Core Domain โดยไม่ต้องมี Entity จำนวนมาก ขณะที่ CRUD ที่ต้อง scale สูงยังคงมี domain logic เรียบง่าย

Core, Supporting และ Generic#

DDD Reference วาง Core Domain เป็นส่วนที่มี คุณค่ากลยุทธ์สูงและสมควรได้รับ talent/investment เพื่อทำให้ model ลึก ส่วนการแบ่งย่อยแบบ practical:

Classification เป็น portfolio hypothesis ไม่ใช่คุณสมบัติถาวร Tax calculation อาจ Generic เมื่อใช้ vendor ได้ แต่เป็น Core หากบริษัทแข่งขันด้วย cross-border tax optimization ที่ตนพัฒนาเอง

System map

ภาพนี้เป็น starting heuristic ไม่ใช่ classification algorithm โดยเฉพาะกล่อง Impact ซึ่งเตือนว่า Generic หรือ Supporting ที่เกี่ยวกับเงินอาจต้องลงทุนด้าน controls สูงแม้ไม่ใช่ differentiator

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

Authentication, backup, regulatory reporting และ notification อาจ operationally critical มาก แม้ไม่สร้าง differentiation ให้ธุรกิจ จงประเมิน 4 แกนแยก:

1. Differentiation — ลูกค้า/strategy เห็นความต่างหรือไม่
2. Domain complexity — model/policy ยากเพียงใด
3. Failure impact — ผิดแล้วเสียเงิน สิทธิ์ availability หรือ reputation เท่าใด
4. Compliance/security — มี authority/control/evidence ใดบังคับ

Supporting Subdomain ที่กระทบเงินอาจต้อง invariant, audit evidence และ strong control มากกว่า Core ที่เป็น recommendation algorithm แต่ไม่มี financial authority

Capability ไม่เท่ากับ Product หรือ Application#

อย่าจำแนก Wallet ทั้งก้อนเป็น Core เพราะ product หนึ่งประกอบหลาย capabilities:

ให้ business owner, supporting evidence และ review trigger อยู่ข้าง classification เพราะ strategy และความได้เปรียบทางธุรกิจเปลี่ยนได้

Build, Buy, Partner หรือ Retire#

ใช้คำถาม:

• differentiation อยู่ที่ algorithm/policy หรือเพียง integration experience
• vendor กำหนด model จน product strategy ถูกจำกัดหรือไม่
• switching/translation cost คืออะไร
• data/control requirement อนุญาต outsourcing เพียงใด
• internal team มี domain knowledge และ operational capacity หรือไม่
• capability ยังสร้าง value หรือควรถูก retire

การซื้อ Generic capability ยังต้องมี ACL และ contract ownership หาก vendor language ไม่ตรงกับ context ภายใน การสร้างเองก็ไม่ได้แปลว่า Rich Domain Model เสมอ หาก rule เรียบง่าย

Core Domain Chart และเวลาที่เปลี่ยน#

DDD Crew Core Domain Charts ใช้ collaboration เพื่อคุย business differentiation กับ model complexity ตามเวลา แกนเวลาช่วยเห็นว่า capability อาจเดินจาก Core ไป Commodity เมื่อคู่แข่ง/ตลาดตามทัน หรือกลับเป็น Core เมื่อ strategy ใหม่เกิด

บันทึก:

Capability:
Current strategic hypothesis:
Evidence / customer outcome:
Domain complexity:
Criticality and compliance risk:
Build / buy / partner / retire decision:
Investment deliberately chosen:
Owner and review date:
Trigger that changes classification:

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

จำแนก capabilities 8 รายการ: Customer Identity, Eligibility Decision, Provider Routing, Provider Connectivity, Funds Availability, Ledger Posting, Notification และ Tax Calculation ภายใต้ 2 strategies:

1. บริษัทแข่งขันด้วย transfer success rate และ transparent pricing
2. บริษัท white-label provider รายเดียวและแข่งขันด้วย merchant onboarding

ทุกแถวต้องมี evidence, uncertainty และสิ่งที่ ไม่สรุป จาก classification เช่น Core ไม่ได้แปลว่า ต้องแยก microservice หรือใช้ Event Sourcing

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

• แยก business complexity จาก technical complexity
• แยก differentiation, criticality และ compliance risk
• จำแนก capability ไม่เหมารวมทั้ง product/application
• Classification มี owner, evidence และ review date
• Build/buy/partner พิจารณา translation และ operational cost
• Core ไม่ถูก map ไป architecture pattern อัตโนมัติ
• Strategy เปลี่ยนแล้ว classification เปลี่ยนได้

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

• DDD Reference — Core Domain และ Generic Subdomain
• Core Domain Charts — collaborative strategic tool
• DDD Starter Modelling Process — Strategize activity และ iterative flow