ตอนที่ 4 ของซีรีส์ Domain-Driven Design ฉบับระบบธุรกิจจริง

หลังจากตอนที่ 3 เราได้ภาษาเดียวกันระหว่างโค้ดกับธุรกิจแล้ว

ตอนนี้ถึงเวลาลงมือ สร้าง Domain Model จริง ๆ

คำถามแรกที่สำคัญมากคือ:

สิ่งนี้ในระบบ ควรเป็น Entity หรือ Value Object ?

ถ้าตัดสินใจผิดตั้งแต่ตรงนี้ Domain จะเริ่มบิดทันที

---

ความเข้าใจผิดที่พบบ่อย

นักพัฒนาระบบธุรกิจจำนวนมากมักคิดว่า:

“อะไรก็ตามที่มาจาก database = Entity”

ผลลัพธ์คือ:

• ทุกอย่างมี id
• ทุกอย่างแก้ค่าได้หมด
• Domain กลายเป็นถุงข้อมูล (Anemic Model)

DDD แยกสิ่งเหล่านี้ออกชัดเจนกว่า

---

Entity คืออะไร

Entity คือสิ่งที่:

• มีตัวตนเฉพาะ (identity)
• เปลี่ยนค่าได้ แต่ยังเป็น “สิ่งเดิม”
• ธุรกิจสนใจว่า เป็นใคร มากกว่า มีค่าอะไร

ในระบบพนักงาน ตัวอย่าง Entity ได้แก่:

• Staff
• ShiftRequest
• Department

แม้ข้อมูลจะเปลี่ยน แต่ identity ยังเดิม

---

ตัวอย่าง Entity: Staff

class Staff {
  final StaffId id;
  String name;
  StaffStatus status;

  void resign() {
    if (status == StaffStatus.resigned) {
      throw Exception('Staff already resigned');
    }
    status = StaffStatus.resigned;
  }
}

ประเด็นสำคัญ:

• id คือหัวใจของ entity
• behavior อยู่กับ entity
• entity ปกป้องกฎของตัวเอง

---

Value Object คืออะไร

Value Object คือสิ่งที่:

• ไม่มี identity
• วัดค่าด้วย “ความเท่ากันของข้อมูล”
• มักเป็น immutable

ในระบบพนักงาน ตัวอย่าง Value Object ได้แก่:

• EmailAddress
• PhoneNumber
• WorkingPeriod
• ShiftTime

ถ้าค่าเหมือนกัน = ถือว่าเหมือนกัน

---

ตัวอย่าง Value Object: WorkingPeriod

class WorkingPeriod {
  final DateTime start;
  final DateTime end;

  WorkingPeriod(this.start, this.end) {
    if (!end.isAfter(start)) {
      throw Exception('End must be after start');
    }
  }

  bool overlaps(WorkingPeriod other) {
    return start.isBefore(other.end) && end.isAfter(other.start);
  }
}

จุดสังเกต:

• ไม่มี id
• สร้างแล้วแก้ไม่ได้
• กฎอยู่ในตัวมันเอง

---

ทำไม Value Object ถึงสำคัญกับระบบธุรกิจ

ถ้าคุณไม่ใช้ Value Object:

• validation จะกระจัดกระจาย
• logic ซ้ำ ๆ เต็มระบบ
• test ยาก

Value Object ทำให้:

• กฎถูกเขียนครั้งเดียว
• intent ชัดเจน
• domain อ่านง่ายขึ้นมาก

---

Entity + Value Object ทำงานร่วมกัน

Entity ไม่ควรเก็บ primitive ดิบ ๆ เต็มไปหมด แต่ให้ใช้ชนิดข้อมูลที่เป็น value object มาทำงานร่วมกัน

แทนที่จะเขียน:

String email;
DateTime shiftStart;
DateTime shiftEnd;

ให้เขียน:

EmailAddress email;
WorkingPeriod shiftPeriod;

ตอนนี้ domain:

• ปลอดภัยขึ้น เพราะ ค่า email หรือ shiftPeriod จะถูกตรวจสอบความถูกต้องของข้อมูลจาก value object ซึ่งก็คือ class EmailAddress และ WorkingPeriod เป็นต้น
• อ่านเหมือนภาษาธุรกิจ
• ลด bug เชิงกฎ

---

Checklist ตัดสินใจ: Entity หรือ Value Object

ถามตัวเองทีละข้อ:

1. ธุรกิจสนใจ identity ของมันไหม?
2. ถ้าข้อมูลเหมือนกัน ถือว่าเป็นอันเดียวกันได้ไหม?
3. มันควรถูกแก้ไข หรือควรถูกแทนที่?

ถ้า:

• สนใจ identity → Entity
• สนใจค่า → Value Object

---

สรุปตอนที่ 4

• Entity = ตัวตน + behavior
• Value Object = ค่า + กฎ + immutability
• ใช้ให้ถูกตั้งแต่ต้น = domain แข็งแรง

ถ้าทุกอย่างในระบบเป็น Entity

แปลว่าคุณยังไม่ได้ออกแบบ Domain จริง ๆ

---

ตอนต่อไป

ตอนที่ 5: Aggregate & Aggregate Root – กำแพงป้องกัน Domain ไม่ให้เละ

เราจะเริ่มควบคุมขอบเขตของการแก้ไข และพูดถึง invariants ของระบบพนักงาน

ตอนที่ 2 ของซีรีส์ Domain-Driven Design ฉบับระบบธุรกิจจริง

Theme หลัก: ระบบบริหารพนักงาน (Staff / Employee Management System)

ในตอนที่แล้ว เราคุยกันว่า DDD คือการเปลี่ยนมุมมองการออกแบบระบบ โดยให้ Domain เป็นศูนย์กลาง

ตอนนี้เราจะลงลึกขึ้นอีกขั้น ด้วยการดูว่า

วิธีคิดในการเขียนโค้ดของเราเอง ส่งผลยังไงต่อการหายไปของ domain

และทำไมการเปลี่ยนจาก Imperative → Declarative → Domain Thinking ถึงสำคัญมาก

---

จุดเริ่มต้นของปัญหา: Imperative Thinking

Imperative thinking คือการเขียนโค้ดแบบ:

“ทำทีละขั้น ให้ได้ผลลัพธ์ตามที่ต้องการ”

ตัวอย่างที่พบได้บ่อยในระบบพนักงาน:

void approveShiftRequest(String requestId, String approverId) {
  final request = repository.findById(requestId);

  if (request == null) return;
  if (request.status != 'PENDING') return;
  if (!userService.isManager(approverId)) return;

  request.status = 'APPROVED';
  request.approvedBy = approverId;
  request.approvedAt = DateTime.now();

  repository.save(request);
}

โค้ดนี้ ทำงานได้ และดูเหมือนจะโอเค

แต่ลองถามตัวเองว่า:

• กฎของธุรกิจอยู่ตรงไหน?
• อะไรคือสิ่งที่ “ห้าม” เกิดขึ้น?
• ถ้ากฎเปลี่ยน ใครเป็นคนรับผิดชอบ?

คำตอบคือ: ไม่มีที่ชัดเจน

---

เมื่อโค้ดบอก “ยังไง” แต่ไม่บอก “อะไร”

โค้ดแบบ Imperative มักมีปัญหาเหล่านี้:

• อ่านแล้วรู้ลำดับ แต่ไม่รู้ความหมาย
• Business rule ซ่อนอยู่ใน if-else
• ชื่อ method ไม่สะท้อน intent ของธุรกิจ

ในตัวอย่างก่อนหน้า:

• status != 'PENDING' คือกฎ หรือแค่ technical check?
• ใครควรมีสิทธิ์ approve จริง ๆ?
• อนุมัติซ้ำได้ไหม?

คำถามเหล่านี้ ไม่ถูกตอบใน domain แต่กระจายอยู่ใน service

---

Declarative Thinking: บอก “อะไร” แทน “ยังไง”

Declarative thinking คือการเขียนโค้ดแบบ:

“ระบบควรอนุญาตให้เกิดอะไรได้บ้าง”

ลองปรับมุมมองใหม่:

shiftRequest.approve(by: approver);

ประโยคนี้สั้น แต่มีความหมายทางธุรกิจชัดเจนมาก

คำถามสำคัญคือ:

แล้วกฎทั้งหมดหายไปไหน?

คำตอบคือ: มันควรไปอยู่ใน Domain

---

Domain Thinking: ให้ Domain ปกป้องกฎของตัวเอง

ลองดูตัวอย่าง Domain Model ของ ShiftRequest

class ShiftRequest {
  ShiftRequestStatus status;
  String? approvedBy;
  DateTime? approvedAt;

  void approve(Staff approver) {
    if (status != ShiftRequestStatus.pending) {
      throw Exception('Request is not pending');
    }

    if (!approver.isManager) {
      throw Exception('Only manager can approve');
    }

    status = ShiftRequestStatus.approved;
    approvedBy = approver.id;
    approvedAt = DateTime.now();
  }
}

ตอนนี้:

• กฎอยู่กับข้อมูลที่มันควบคุม
• ไม่มีใครข้ามกฎนี้ได้
• อ่านโค้ดแล้วเข้าใจธุรกิจทันที

นี่คือ Domain Thinking

---

เปลี่ยนบทบาทของ Service และ Use Case

เมื่อ domain แข็งแรง:

• Service / Use Case ไม่ต้องรู้รายละเอียดกฎ
• ทำหน้าที่แค่ ประสานงาน (orchestration)

ตัวอย่าง Use Case:

void approveShiftRequest(String requestId, String approverId) {
  final request = repository.findById(requestId);
  final approver = staffRepository.findById(approverId);

  request.approve(approver);

  repository.save(request);
}

Use Case อ่านเหมือนขั้นตอนธุรกิจ ไม่ใช่ logic ยิบย่อย

---

ทำไม mindset นี้ถึงสำคัญกับระบบธุรกิจ

ระบบธุรกิจมีลักษณะร่วมกัน:

• กฎเปลี่ยนบ่อย
• Exception เยอะ
• ข้อยกเว้นสำคัญกว่ากรณีปกติ

ถ้า logic กระจัดกระจาย:

• แก้กฎหนึ่งครั้ง = เสี่ยงทั้งระบบ
• Test ยาก
• ไม่มีใครมั่นใจว่า logic ครบจริง

Domain Thinking ทำให้:

• กฎมีเจ้าของชัดเจน
• Test domain ได้โดยไม่ต้องพึ่ง UI หรือ DB
• ระบบโตโดยไม่เสียรูป

---

สรุปตอนที่ 2

• Imperative: บอกระบบว่า ทำยังไง
• Declarative: บอกระบบว่า อะไรควรเกิด
• Domain Thinking: ให้ domain เป็นผู้ตัดสิน

ถ้า Domain ของคุณไม่มี behavior

นั่นแปลว่ากฎของธุรกิจอาจกำลังลอยอยู่ผิดที่

---

ตอนต่อไป

ตอนที่ 3: Ubiquitous Language – ภาษาที่โค้ดกับธุรกิจพูดตรงกัน

เราจะเริ่มจากการตั้งชื่อผิด ๆ ในระบบพนักงาน แล้วค่อยแก้ให้โค้ดกลายเป็นภาษาของธุรกิจจริง ๆ

ตอนที่ 3 ของซีรีส์ Domain-Driven Design ฉบับระบบธุรกิจจริง

Theme หลัก: ระบบบริหารพนักงาน (Staff / Employee Management System)

ในตอนที่ 2 เราเห็นแล้วว่า Domain Thinking คือการให้ domain เป็นผู้ตัดสินกฎของธุรกิจ

แต่ถึง domain จะอยู่ถูกที่แล้ว ระบบก็ยังพังได้ ถ้าเราใช้ “ภาษา” ผิด

DDD เรียกภาษานี้ว่า Ubiquitous Language

---

ปัญหาที่แท้จริง: เราคุยกันคนละภาษา

ลองนึกถึงบทสนทนาแบบนี้ในระบบพนักงาน:

• ฝ่าย HR: “พนักงานยื่น คำขอเปลี่ยนกะ ได้วันละ 1 ครั้ง”
• Developer: “โอเค เดี๋ยวเช็ค field request_count”
• Code: canEdit = status != 2 && role != 3

ทุกคนคิดว่าตัวเองเข้าใจตรงกัน แต่จริง ๆ แล้ว:

• ธุรกิจพูดถึง คำขอ (Request)
• โค้ดพูดถึง ตัวเลขและสถานะลอย ๆ

ผลลัพธ์คือ ระบบที่:

ไม่มีใครมั่นใจว่าโค้ดสะท้อนกฎจริงครบหรือยัง

---

Ubiquitous Language คืออะไร

Ubiquitous Language (Ubiquitous อ่านว่า ยูบิค ควิเทิส) คือ:

ภาษาชุดเดียว ที่ถูกใช้ ร่วมกัน ระหว่าง

• คนธุรกิจ
• เอกสาร
• โค้ด
• การทดสอบ

ถ้าธุรกิจเรียกว่า “คำขอเปลี่ยนกะ”

โค้ดก็ต้องเรียกว่า:

• ShiftChangeRequest
• ไม่ใช่ RequestModel
• ไม่ใช่ Transaction

ชื่อในโค้ด ไม่ควรแปล หรือย่อความหมายของธุรกิจ

---

ตัวอย่างชื่อที่ทำให้ Domain พัง

ในระบบพนักงาน มักเจอชื่อแบบนี้:

• status = 1, 2, 3
• type = ‘A’
• flag = true
• role = 99

โค้ดอาจทำงานได้ แต่คำถามคือ:

• status = 2 แปลว่าอะไร?
• ใครเป็นคนตัดสิน?
• กฎนี้มาจากไหน?

ถ้าต้องเปิดเอกสารหรือถามคนอื่นทุกครั้ง แปลว่า ภาษาไม่ ubiquitous

---

เปลี่ยนตัวเลขให้เป็นภาษาธุรกิจ

แทนที่จะเขียนแบบนี้:

if (request.status != 1) return;

ให้เขียนแบบนี้:

enum ShiftRequestStatus {
  pending,
  approved,
  rejected,
  cancelled,
}

if (request.status != ShiftRequestStatus.pending) return;

ตอนนี้โค้ด:

• อ่านแล้วรู้ความหมายทันที
• ตรงกับภาษาที่ HR ใช้
• ลดการตีความผิด

---

Ubiquitous Language ต้องอยู่ทุกที่

ภาษานี้ไม่ควรอยู่แค่ใน code

แต่ควรอยู่ใน:

• ชื่อ class / method
• test case
• commit message
• document

ตัวอย่าง test:

test('manager can approve pending shift request', () {
  // ...
});

ถ้าอ่าน test แล้ว HR เข้าใจได้ แปลว่าคุณมาถูกทางแล้ว

---

ระวังคำที่ดู technical เกินไป

คำบางคำดูเหมือนจะโอเค แต่จริง ๆ แล้วอันตราย:

• process
• handle
• manage
• data

เช่น:

• processRequest() → ทำอะไร?
• handleStaff() → handle ยังไง?

ให้ถามตัวเองว่า:

ธุรกิจใช้คำนี้จริงไหม?

ถ้าไม่ ให้เปลี่ยน

---

สร้างภาษาไปพร้อมกับธุรกิจ

Ubiquitous Language ไม่ใช่สิ่งที่คิดครั้งเดียวแล้วจบ

มันต้อง:

• evolve ตามความเข้าใจ
• ถูกแก้เมื่อพบว่าคำเดิมไม่ชัด
• กล้าลบชื่อเก่า แม้จะเขียนไปแล้ว

การ refactor ชื่อ:

ไม่ใช่งาน cosmetic แต่เป็นงานออกแบบ domain

---

สรุปตอนที่ 3

• ภาษา คือโครงสร้างของความคิด
• ชื่อที่ไม่ชัด = domain ที่พัง
• โค้ดควรอ่านเหมือนประโยคธุรกิจ

ถ้าคุณอธิบายระบบโดยเปิดโค้ดให้ฝ่ายธุรกิจดูไม่ได้

นั่นแปลว่าภาษาของระบบยังไม่ ubiquitous

---

ตอนต่อไป

ตอนที่ 4: Entity vs Value Object – สิ่งไหนควรมีตัวตนในระบบพนักงาน

เราจะเริ่มแตก domain model ของระบบพนักงานอย่างจริงจัง ว่าอะไรคือ entity อะไรคือ value object

ตอนที่ 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 น่าจะเป็นสิ่งที่คุณกำลังมองหาอยู่