บทนำ

ในระบบธุรกิจจริง หลายสิ่งไม่ได้เกิดขึ้นเพราะ “มีคนสั่ง” เสมอไป แต่เกิดขึ้นเพราะ เหตุการณ์บางอย่างได้เกิดขึ้นแล้ว

เช่น:

• พนักงานผ่านทดลองงาน
• พนักงานลาออก
• เงินเดือนถูกปรับ
• แผนกถูกยุบ

เหตุการณ์เหล่านี้คือหัวใจของแนวคิดที่เรียกว่า Domain Event ใน Domain-Driven Design (DDD)

---

Domain Event คืออะไร

Domain Event คือ object ที่ใช้แทน “เหตุการณ์สำคัญทางธุรกิจ” ที่ได้เกิดขึ้นแล้วใน Domain

คุณสมบัติสำคัญ:

• เป็นเหตุการณ์ในอดีต (past tense)
• มีความหมายทางธุรกิจชัดเจน
• เกิดจาก Domain Model ไม่ใช่ UI

ตัวอย่าง Domain Event:

• EmployeePassedProbation
• EmployeeSalaryAdjusted
• EmployeeResigned

---

ทำไม Domain Event ถึงสำคัญ

หากไม่มี Domain Event:

• ระบบจะ tightly coupled
• Logic จะกระจุกอยู่ที่ Use Case
• Feature ใหม่เพิ่มยาก

Domain Event ช่วยให้:

• ระบบขยายได้โดยไม่ต้องแก้โค้ดเดิม
• แยกผลกระทบออกจากต้นเหตุ
• Domain สื่อสารสิ่งที่เกิดขึ้นได้ชัดเจน

ธุรกิจคิดเป็น “เหตุการณ์” ไม่ใช่ “ฟังก์ชัน”

---

ตัวอย่างจากระบบพนักงาน

เหตุการณ์: พนักงานผ่านทดลองงาน

เมื่อเหตุการณ์นี้เกิดขึ้น:

• เปลี่ยนสถานะพนักงานเป็น permanent
• แจ้งฝ่าย payroll
• ส่งอีเมลแจ้ง HR
• เปิดสิทธิประโยชน์ใหม่

แทนที่จะเขียนทั้งหมดใน Use Case เดียว

Domain Model จะ:

• สร้าง Domain Event: EmployeePassedProbation

ส่วนระบบอื่นจะ:

• subscribe เหตุการณ์นี้ไปจัดการงานของตัวเอง

---

Domain Event ทำงานร่วมกับ Aggregate อย่างไร

Domain Event:

• ถูกสร้างภายใน Aggregate
• สะท้อนการเปลี่ยนแปลง state ที่สำคัญ
• ไม่ควรรู้ว่าใครจะรับไปใช้

ตัวอย่างเชิงแนวคิด:

Employee Aggregate
  └─ changeStatus()
        └─ raise EmployeePassedProbation event

---

Domain Event vs Application Event

หัวข้อ	Domain Event	Application / Integration Event
แหล่งที่มา	Domain Model	Application / Infra
ความหมาย	ธุรกิจ	เทคนิค / integration
ภาษา	ภาษา Domain	ภาษาระบบ

Domain Event ต้องใช้ Ubiquitous Language เสมอ

---

Domain Event ควรถูก handle ที่ไหน

โดยทั่วไป:

• Aggregate → สร้าง event
• Application Service → publish event
• Event Handler → ทำงานต่อ

Event Handler:

• ส่ง email
• เรียก external system
• update read model

Domain Model ไม่ควรรู้จัก event handler

---

ข้อควรระวังในการใช้ Domain Event

• อย่าใช้กับทุกการเปลี่ยนแปลงเล็ก ๆ
• ใช้เฉพาะเหตุการณ์ที่ธุรกิจ “สนใจจริง”
• อย่าใส่ logic หนักใน event handler

Domain Event ที่ดี:

• เล็ก
• ชัด
• สื่อความหมายธุรกิจ

---

สรุป

• Domain Event คือเหตุการณ์สำคัญทางธุรกิจ
• ช่วยลด coupling และเพิ่มความยืดหยุ่น
• ทำให้ระบบคิดและสื่อสารแบบธุรกิจจริง
• เป็นก้าวสำคัญของระบบที่ scale ได้

ตอนถัดไป เราจะเชื่อมทุกอย่างเข้าด้วยกันด้วย Architecture Patterns (Layered, Clean, Hexagonal) เพื่อปิดแกนหลักของ DDD

---

บทนำ

เมื่อพูดถึงคำว่า Repository นักพัฒนาจำนวนมากมักจะนึกถึงไฟล์ที่มีแต่ create, read, update, delete

แต่ใน Domain-Driven Design (DDD) นั้น Repository มีความหมายและบทบาทที่ลึกกว่านั้นมาก

บทความตอนนี้จะอธิบายว่า Repository ใน DDD คืออะไร, แตกต่างจาก CRUD แบบทั่วไปอย่างไร และควรออกแบบอย่างไรให้ Domain สะอาดและยั่งยืน โดยใช้ตัวอย่าง ระบบพนักงาน (Employee Management System)

---

Repository ใน Domain-Driven Design คืออะไร

Repository คือ abstraction ที่ทำหน้าที่:

• ทำให้ Domain รู้สึกเหมือนกำลังทำงานกับ object ในหน่วยความจำ
• ซ่อนรายละเอียดของ database, ORM, API หรือ storage ใด ๆ
• ให้ Domain Model โฟกัสกับ business logic โดยไม่ผูกกับเทคโนโลยี

Repository คือ “ภาพลวงตา” ที่ทำให้ Domain คิดว่า object ยังมีชีวิตอยู่ตลอดเวลา

---

Repository ไม่ใช่ DAO และไม่ใช่ CRUD

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

Repository = DAO + CRUD

ใน DDD แนวคิดนี้ ผิดโดยหลักการ

เปรียบเทียบ Repository vs CRUD

หัวข้อ	Repository (DDD)	CRUD / DAO
มุมมอง	Domain-centric	Database-centric
คืนค่า	Aggregate	Record / Row
เมธอด	ใช้ภาษา Domain	ใช้ภาษาเทคนิค
ผู้ใช้งาน	Domain / Application Service	Controller / Service

Repository ถูกออกแบบมาเพื่อ Aggregate ไม่ใช่ table

---

ตัวอย่างจากระบบพนักงาน

Aggregate: Employee

สิ่งที่ Repository ควรมี:

• findById(EmployeeId id)
• save(Employee employee)
• findActiveEmployees()

สิ่งที่ Repository ไม่ควรมี:

• updateSalaryById()
• deleteByDepartmentId()
• findBySalaryGreaterThan() (ถ้าไม่ใช่ภาษา Domain)

ถ้า method ไหนอ่านแล้วไม่ใช่ภาษาของธุรกิจ นั่นคือสัญญาณเตือน

---

Repository ทำงานร่วมกับ Application Service อย่างไร

Repository ไม่ควรถูกเรียกโดย UI หรือ Controller โดยตรง

โครงสร้างที่เหมาะสมคือ:

UI / API
   ↓
Application Service / Use Case
   ↓
Repository
   ↓
Domain Model (Aggregate)

Application Service:

• ตัดสินใจว่า use case ต้องโหลดอะไร
• เรียก Repository
• ส่ง Aggregate ให้ Domain ทำงานต่อ

---

ทำไม Repository ควรคืนค่าเป็น Aggregate

เพราะ:

• Aggregate คือ boundary ของ consistency
• Business rule ถูกคุมอยู่ภายใน
• ป้องกันการแก้ state แบบข้ามกฎ

ถ้า Repository คืนค่าเป็น DTO หรือ Map:

• Domain จะอ่อนแรง
• Invariant จะถูกละเมิดง่าย
• Logic จะไหลไปอยู่ผิดที่

---

Repository กับ Infrastructure

ใน DDD:

• Interface ของ Repository อยู่ใน Domain Layer
• Implementation อยู่ใน Infrastructure Layer

Domain:

• ไม่รู้จัก database
• ไม่รู้จัก ORM
• ไม่รู้จัก framework

Infrastructure:

• แปลง Aggregate ↔ persistence model
• จัดการ transaction ระดับเทคนิค

---

สัญญาณว่า Repository ของคุณเริ่มผิดทาง

• Repository มี method เยอะผิดปกติ
• Method name เต็มไปด้วยเงื่อนไขเชิง query
• Business logic เริ่มไหลเข้า Repository
• Aggregate กลายเป็น data holder

ถ้าเห็นสัญญาณเหล่านี้ แปลว่าคุณกำลังหลุดจาก DDD

---

สรุป

• Repository ใน Domain-Driven Design ไม่ใช่ CRUD
• ถูกออกแบบเพื่อ Aggregate ไม่ใช่ table
• ใช้ภาษา Domain ไม่ใช่ภาษา database
• ช่วยปกป้อง business rule และโครงสร้างของ Domain

ในตอนถัดไป เราจะพูดถึง Domain Event – เมื่อระบบธุรกิจขับเคลื่อนด้วยเหตุการณ์ ซึ่งเป็นก้าวสำคัญของระบบที่ scale ได้จริง

บทนำ

หลังจากตอนที่ 6 เราได้รู้จัก Domain Service ซึ่งเป็นที่อยู่ของ business logic ที่ไม่ควรผูกกับ Entity ใดโดยตรง

คำถามถัดมาที่มักจะตามมาคือ:

แล้วโค้ดที่รับ request จาก UI, เรียก Domain Service, ใช้ Repository และจัดการ transaction ควรอยู่ที่ไหน?

คำตอบคือ Application Service (หรือที่หลายทีมเรียกว่า Use Case)

---

Application Service คืออะไร

Application Service คือชั้นที่ทำหน้าที่:

• รับคำสั่งจากภายนอก (UI, API, Controller)
• ประสานงานระหว่าง Domain Objects
• ควบคุม flow ของ use case หนึ่ง ๆ
• จัดการ transaction, permission, orchestration

❗ Application Service ไม่ใช่ ที่อยู่ของ business rule เชิงลึก

มันคือ “ผู้จัดการกระบวนการ” ไม่ใช่ “ผู้ตัดสินกฎธุรกิจ”

---

เปรียบเทียบง่าย ๆ ด้วยระบบพนักงาน

สมมติ use case: ปรับเงินเดือนพนักงาน

สิ่งที่ Application Service ทำ:

1. รับคำสั่งปรับเงินเดือนจาก UI
2. โหลด Employee Aggregate จาก Repository
3. เรียก Domain Service เพื่อตรวจสอบกฎธุรกิจ
4. สั่งให้ Aggregate เปลี่ยนสถานะ
5. บันทึกผลลัพธ์กลับ Repository

สิ่งที่ Application Service ไม่ควรทำ:

• คำนวณสูตรเงินเดือนเอง
• ตรวจสอบ policy เชิงลึกของบริษัท
• เขียน if/else ธุรกิจยาว ๆ

---

ตัวอย่างโครงสร้าง (เชิงแนวคิด)

UI / API
   ↓
Application Service (Use Case)
   ↓
Domain Model (Entity, Value Object, Domain Service)
   ↓
Repository

Application Service คือสะพานเชื่อมโลกภายนอกกับ Domain

---

ตัวอย่างเชิงโค้ด (pseudo code)

class AdjustSalaryUseCase {
  execute(command) {
    employee = employeeRepository.getById(command.employeeId)

    salaryPolicyService.validate(employee, command.newSalary)

    employee.adjustSalary(command.newSalary)

    employeeRepository.save(employee)
  }
}

สังเกตว่า:

• ไม่มี logic ธุรกิจซับซ้อนอยู่ใน Use Case
• Business rule อยู่ใน Domain
• Use Case ทำหน้าที่เรียงลำดับขั้นตอนเท่านั้น

---

Application Service vs Domain Service

หัวข้อ	Application Service	Domain Service
โฟกัส	Flow / Use case	Business rule
รู้จัก UI	รู้	ไม่รู้
รู้จัก Persistence	รู้	ไม่รู้
Stateless	ส่วนใหญ่ใช่	ใช่

ถ้า logic นั้นเปลี่ยนเพราะ ขั้นตอนทำงานเปลี่ยน → Application Service

ถ้า logic นั้นเปลี่ยนเพราะ กฎธุรกิจเปลี่ยน → Domain Service

---

ทำไม Application Service ถึงสำคัญมาก

ถ้าไม่มี Application Service:

• Controller จะอ้วน
• Business logic กระจัดกระจาย
• Test ยาก
• Domain ถูกใช้ผิดวิธี

Application Service ช่วยให้:

• Use case ชัดเจน
• อ่านโค้ดแล้วรู้ว่า “ระบบทำอะไรได้บ้าง”
• Domain สะอาดและคงทนต่อการเปลี่ยนแปลง

---

สรุป

• Application Service คือ ผู้ควบคุม flow ของระบบ
• ไม่ใช่ที่อยู่ของ business rule
• เป็นสะพานเชื่อม UI กับ Domain
• ทำให้ระบบ scale ทางความซับซ้อนได้โดยไม่เละ

ตอนนี้ Domain ของคุณเริ่มแข็งแรงแล้ว

ตอนถัดไป เราจะลงลึกเรื่อง Repository – มุมมองแบบ DDD vs CRUD ซึ่งเป็นอีกจุดที่หลายทีมเข้าใจผิดมาก

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

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

ในตอนที่ 5 เราใช้ Aggregate เพื่อกำหนดขอบเขตและปกป้อง invariant ของ domain

แต่เมื่อเริ่มออกแบบจริง คุณจะเจอสถานการณ์แบบนี้:

logic นี้เป็นกฎของธุรกิจแน่ ๆ … แต่ไม่รู้จะใส่ไว้ใน entity ตัวไหนดี

นี่คือจุดที่ Domain Service เข้ามามีบทบาท

---

ปัญหาที่เจอบ่อยในระบบพนักงาน

ลองดู use case ต่อไปนี้:

• พนักงานขอเปลี่ยนกะ
• ระบบต้องตรวจสอบว่า
  • ไม่ชนกับกะอื่นของพนักงาน
  • ไม่ชนกับกะที่ได้รับอนุมัติแล้ว
  • ไม่เกินนโยบายที่ HR กำหนด

คำถามคือ:

• logic นี้ควรอยู่ใน ShiftRequest?
• หรืออยู่ใน Staff?

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

---

ความเข้าใจผิดเกี่ยวกับ Service

ในระบบทั่วไป เรามักเห็น:

• ShiftService
• StaffService
• RequestService

ที่ภายในเต็มไปด้วย if-else

DDD แยก Service ออกเป็น 3 ประเภท:

1. Application Service (Use Case)
2. Domain Service
3. Infrastructure Service

ตอนนี้เราจะโฟกัสที่ข้อ 2

---

Domain Service คืออะไร

Domain Service คือ:

class ที่รวม logic ทางธุรกิจ

ซึ่ง ไม่เป็นเจ้าของข้อมูลเอง

และ ไม่เหมาะจะอยู่ใน entity ใด entity หนึ่ง

คุณสมบัติสำคัญ:

• อยู่ใน layer ของ domain
• ใช้ภาษาเดียวกับธุรกิจ (Ubiquitous Language)
• ไม่มี state ระยะยาว

---

ตัวอย่าง Domain Service: ShiftPolicy

class ShiftPolicy {
  bool canRequestShift(
    Staff staff,
    WorkingPeriod period,
    List<ShiftRequest> existingRequests,
  ) {
    if (staff.status != StaffStatus.active) return false;

    for (final request in existingRequests) {
      if (request.period.overlaps(period)) {
        return false;
      }
    }

    return true;
  }
}

จุดสำคัญ:

• ไม่เก็บข้อมูลเอง
• รับทุกอย่างผ่าน parameter
• สื่อความหมายเชิงธุรกิจ

---

Domain Service ไม่ใช่ Utility

ข้อผิดพลาดที่พบบ่อยคือ:

class DateUtils {
  static bool overlap(DateTime a, DateTime b) {}
}

นี่คือ Technical Utility

แต่ Domain Service:

• ต้องสะท้อนกฎของธุรกิจ
• ชื่อบอก intent ชัดเจน

ShiftPolicy ดีกว่า ShiftHelper

---

Domain Service ทำงานร่วมกับ Aggregate

Aggregate Root ยังคงเป็นผู้ตัดสินขั้นสุดท้าย

ตัวอย่างใน ShiftRequest:

class ShiftRequest {
  void request(
    Staff staff,
    WorkingPeriod period,
    ShiftPolicy policy,
    List<ShiftRequest> existing,
  ) {
    if (!policy.canRequestShift(staff, period, existing)) {
      throw Exception('Shift request not allowed');
    }

    // สร้าง request
  }
}

Policy ช่วยตัดสิน แต่ aggregate รับผิดชอบ invariant

---

สัญญาณว่าคุณควรใช้ Domain Service

คุณควรพิจารณา Domain Service เมื่อ:

• logic ใช้หลาย entity
• logic ไม่ belong กับ entity เดียว
• การยัด logic ลง entity ทำให้มันอ้วนเกินไป

แต่ถ้า logic เป็นพฤติกรรมของ entity โดยตรง:

อย่ารีบใช้ Domain Service

---

สิ่งที่ Domain Service ไม่ควรทำ

• เรียก database
• รู้จัก framework
• มี side effect ภายนอก

Domain Service ควร:

• pure
• test ง่าย
• ย้ายได้โดยไม่กระทบ infrastructure

---

สรุปตอนที่ 6

• Domain Service = logic ธุรกิจที่ไม่มีตัวตน
• ใช้เมื่อ entity ไม่เหมาะจะรับภาระนั้น
• อย่าใช้แทน entity แบบพร่ำเพรื่อ

ถ้า service ของคุณรู้จัก database

นั่นไม่ใช่ Domain Service

---

ตอนต่อไป

ตอนที่ 7: Application Service / Use Case – หัวใจของการไหลของระบบ

เราจะประกอบ domain ทั้งหมดเข้าด้วยกัน และดูว่า controller ควรบางแค่ไหน

ตอนที่ 5 ของซีรีส์ Domain-Driven Design ฉบับระบบธุรกิจจริง
Theme หลัก: ระบบบริหารพนักงาน (Staff / Employee Management System)

หลังจากตอนที่ 4 เราแยก Entity และ Value Object ได้แล้ว

ขั้นต่อไปที่สำคัญไม่แพ้กันคือคำถามนี้:

ใครมีสิทธิ์แก้ใครได้บ้าง?

ถ้าไม่กำหนดขอบเขตให้ชัด Domain จะเริ่ม “เละ” แบบไม่รู้ตัว

DDD ใช้แนวคิดนี้เพื่อแก้ปัญหา: Aggregate

---

ปัญหาที่เจอบ่อยในระบบพนักงาน

ลองดูสถานการณ์คุ้น ๆ:

• หน้าจอหนึ่งแก้ ShiftRequest.status
• อีกหน้าหนึ่งแก้ approvedBy
• Batch job มาแก้ approvedAt

ทุกอย่างเขียนถูก type

แต่สุดท้ายเกิดคำถามว่า:

• กฎยังครบไหม?
• ใครเป็นคนรับผิดชอบ?
• invariant ถูกทำลายไปหรือเปล่า?

นี่คือสัญญาณว่า ยังไม่มี Aggregate

---

Aggregate คืออะไร

Aggregate คือ:

กลุ่มของ Entity และ Value Object ที่ต้องถูกดูแลเป็นหน่วยเดียวกัน

โดยมี Aggregate Root เป็นประตูทางเข้าเพียงทางเดียว

หลักการสำคัญ:

• แก้ข้อมูลภายใน aggregate ได้ ผ่าน root เท่านั้น
• Root เป็นผู้ปกป้องกฎ (invariants)

---

Aggregate Root คืออะไร

Aggregate Root คือ Entity ตัวหลักที่:

• มี identity
• เป็นจุดเดียวที่ภายนอกเรียกใช้ได้
• รับผิดชอบความถูกต้องของทั้ง aggregate

ในระบบพนักงาน ตัวอย่าง Aggregate Root:

• ShiftRequest
• Staff

---

ตัวอย่าง Aggregate: ShiftRequest

มาดูโครงสร้างแบบง่าย:

class ShiftRequest {
  final ShiftRequestId id;
  ShiftRequestStatus status;
  StaffId staffId;
  WorkingPeriod period;
  Approval approval;

  void approve(Staff approver) {
    if (status != ShiftRequestStatus.pending) {
      throw Exception('Only pending request can be approved');
    }

    approval = Approval.by(approver.id);
    status = ShiftRequestStatus.approved;
  }
}

Approval อาจเป็น Value Object ภายใน aggregate

ภายนอก ไม่ควร ไปแก้ approval ตรง ๆ

---

Invariant: กฎที่ห้ามถูกละเมิด

Invariant คือกฎที่ต้องเป็นจริง เสมอ ภายใน aggregate

ตัวอย่าง invariant ของ ShiftRequest:

• request ที่ approved แล้ว ห้ามกลับเป็น pending
• request หนึ่งรายการ อนุมัติได้เพียงครั้งเดียว
• approver ต้องมีสิทธิ์ตามกฎธุรกิจ

กฎเหล่านี้:

ต้องถูกบังคับโดย Aggregate Root

ไม่ใช่ controller หรือ service

---

ทำไม “ห้ามข้าม Aggregate”

ข้อผิดพลาดที่พบบ่อย:

request.approval.approvedBy = approverId; // ❌

โค้ดนี้:

• ข้าม root
• bypass กฎ
• ทำลาย invariant

ถ้าจำเป็นต้องเปลี่ยน:

request.approve(approver); // ✅

---

ขนาดของ Aggregate สำคัญมาก

Aggregate ที่ดีควร:

• เล็กที่สุดเท่าที่จำเป็น
• ไม่ดึงทุกอย่างมารวมกัน

ตัวอย่างที่ควรแยก:

• Staff ไม่ควรเป็น aggregate เดียวกับ ShiftRequest
• ใช้ StaffId อ้างอิงแทน object เต็ม

เหตุผล:

• performance
• concurrency
• ลด coupling

---

Repository ทำงานกับ Aggregate

Repository ควร:

• load / save ทั้ง aggregate
• ไม่ expose object ภายใน

abstract class ShiftRequestRepository {
  ShiftRequest? findById(ShiftRequestId id);
  void save(ShiftRequest request);
}

Repository ไม่ควรมี method อย่าง:

• updateApprovalStatus()
• setApprovedBy()

นั่นคือการรั่วของ domain

---

สรุปตอนที่ 5

• Aggregate = ขอบเขตของความถูกต้อง
• Aggregate Root = ผู้เฝ้าประตู
• Invariant ต้องอยู่ใน aggregate

ถ้าคุณแก้ entity ไหนก็ได้จากที่ไหนก็ได้

นั่นแปลว่า domain ของคุณยังไม่มีเจ้าของ

---

ตอนต่อไป

ตอนที่ 6: Domain Service – เมื่อ logic ไม่ควรอยู่ใน Entity

เราจะดูกรณีที่ logic บางอย่างไม่เหมาะจะอยู่ใน entity แต่ก็ไม่ควรไปอยู่ใน service ทั่วไป