ตอนที่ 1 ของซีรีส์ Domain-Driven Design ฉบับคนทำแอป & เกมจริง
ถ้าคุณเป็น developer ที่เขียนระบบมานานพอ คุณน่าจะเคยเจอสถานการณ์ประมาณนี้:
- โค้ดเขียนถูกหมด แต่ระบบแก้ยาก
- เพิ่ม feature นิดเดียว กระทบไปทั้งระบบ
- business rule กระจัดกระจายอยู่ใน controller, service, widget, หรือแม้แต่ SQL
- ไม่มีใครกล้าแตะโค้ดเก่า เพราะกลัวพัง
คำถามคือ ปัญหานี้เกิดจากภาษา หรือ framework จริงไหม?
คำตอบของ Domain-Driven Design (DDD) คือ: ไม่ใช่
ปัญหาหลักคือ เราออกแบบระบบจากมุมมองที่ผิดตั้งแต่ต้น
Domain-Driven Design ไม่ใช่ Architecture
หลายคนพอได้ยินคำว่า DDD จะนึกถึงสิ่งเหล่านี้ทันที:
- Clean Architecture
- Hexagonal Architecture
- Folder ซับซ้อนหลายชั้น
- Interface เต็มไปหมด
แต่จริง ๆ แล้ว DDD ไม่ใช่ architecture และไม่ใช่ pattern ชุดหนึ่งที่ต้องทำตาม
DDD คือ แนวคิดในการมองและออกแบบระบบ โดยให้ Domain (กฎของธุรกิจ) เป็นศูนย์กลาง
Architecture เป็นเพียง เครื่องมือ ที่ช่วยให้แนวคิดนี้อยู่รอดในโค้ด
แล้ว “Domain” คืออะไรกันแน่?
Domain ไม่ใช่ database
Domain ไม่ใช่หน้าจอ UI
Domain คือ:
ความรู้ กฎ เงื่อนไข และความหมายของสิ่งที่ระบบนี้ถูกสร้างขึ้นมาเพื่อจัดการ
ตัวอย่าง:
- ระบบพนักงาน → กฎการขอ shift, การอนุมัติ, เงื่อนไขเวลา
- ระบบจอง → เงื่อนไขการยกเลิก, การคืนเงิน, การทับซ้อนของเวลา
สิ่งเหล่านี้ ไม่ควรขึ้นกับ UI, database หรือ framework ใด ๆ
ปัญหาของระบบแบบ Data‑Driven / UI‑Driven
ระบบส่วนใหญ่เริ่มจากคำถามแบบนี้:
- มีหน้าจออะไรบ้าง?
- ต้องมีตารางอะไร?
- API endpoint หน้าตาเป็นยังไง?
แล้วโค้ดก็มักจะออกมาในรูปแบบ:
Controller
→ Service
→ Repository
→ Database
ดูเหมือนจะเป็นระเบียบ แต่ปัญหาคือ:
- Business rule ถูกยัดไว้ใน service แบบปนกันหมด
- Entity เป็นแค่ถุงข้อมูล (Anemic Model)
- ชื่อ class/field สื่อความหมายผิดจากธุรกิจจริง
ผลลัพธ์คือ:
ระบบ “ทำงานได้” แต่ไม่สะท้อนความจริงของ domain
DDD เปลี่ยนคำถามตั้งต้น
แทนที่จะถามว่า:
“จะเก็บข้อมูลยังไงดี?”
DDD จะเริ่มจากคำถามว่า:
“ในโลกจริง สิ่งนี้ ควรทำอะไรได้ และ อะไรที่ห้ามเกิดขึ้น“
เช่น:
- พนักงานขึ้นกะได้กี่ครั้งต่อวัน?
- คำขอถูกแก้ไขได้เมื่อไหร่?
- ใครมีสิทธิ์อนุมัติ?
คำถามเหล่านี้คือ Domain Question ไม่ใช่ Technical Question
หัวใจของ DDD ในประโยคเดียว
Business Rule ต้องอยู่ใน Domain และ Domain ต้องไม่พึ่งพาโลกภายนอก
เมื่อทำได้:
- โค้ดจะอ่านเหมือนเอกสารอธิบายธุรกิจ
- การเปลี่ยนกฎไม่กระทบทั้งระบบ
- ระบบโตได้โดยไม่เละ
DDD ไม่ได้ทำให้เขียนโค้ดน้อยลง
ความจริงที่ต้องยอมรับคือ:
- โค้ดจะเยอะขึ้น
- ต้องคิดมากขึ้น
- ช่วงแรกจะช้าลง
แต่สิ่งที่ได้คือ:
- ความชัดเจน
- ความมั่นใจในการแก้ระบบ
- ระบบที่อธิบายตัวเองได้
DDD คือการ ลงทุนระยะยาว ไม่ใช่ shortcut
ตอนต่อไป
ตอนที่ 2: จาก Imperative → Declarative → Domain Thinking
เราจะเริ่มดูว่า mindset แบบเดิมของการเขียนโค้ด ทำให้ domain หายไปจากระบบได้ยังไง และจะเปลี่ยนมุมมองยังไงให้โค้ดสะท้อนความจริงมากขึ้น
ถ้าเราเคยรู้สึกว่า “โค้ดเราไม่ได้ผิด แต่ระบบมันดูไม่ใช่”
DDD น่าจะเป็นสิ่งที่คุณกำลังมองหาอยู่