บทนำ

หลังจากตอนที่ 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 ซึ่งเป็นอีกจุดที่หลายทีมเข้าใจผิดมาก