คุณจัดโครงสร้าง service/architecture สำหรับแอป Laravel ขนาดใหญ่อย่างไร?

Question

IT Interview Practice · Accepted Answer

เมื่อแอปพลิเคชัน Laravel เติบโตขึ้น แนวทาง "fat controller / fat model" แบบเริ่มต้นจะดูแลรักษาได้ยาก แอปขนาดใหญ่ได้ประโยชน์จาก **เลเยอร์สถาปัตยกรรมเพิ่มเติม** เช่น service classes, action classes, repositories, form requests และการจัดระเบียบ domain ที่ชัดเจน เพื่อรักษาให้ business logic เป็นระเบียบ ทดสอบได้ และดูแลรักษาได้

## ปัญหา: ลอจิกไปอยู่ผิดที่

```text
Small apps: logic in controllers and models is fine.
Large apps: controllers get bloated, models become "god objects", logic is duplicated
→ hard to test, maintain, and reason about. Extract logic into dedicated layers.
```

## service classes — ห่อหุ้ม business logic

```php
<?php
// move complex business logic out of controllers into a service
class OrderService {
    public function __construct(
        private PaymentGateway $payments,
        private InventoryService $inventory,
    ) {}

public function placeOrder(User $user, array $items): Order {
        // orchestrate the business process — reusable, testable, focused
        DB::transaction(function () use ($user, $items) { /* ... */ });
    }
}

// the controller stays THIN — just delegates
public function store(StoreOrderRequest $request, OrderService $orders) {
    return $orders->placeOrder($request->user(), $request->validated());
}
```

**service classes** เก็บ business logic ไว้ ทำให้ controllers บาง (จัดการแค่ HTTP) และ models โฟกัสที่ข้อมูล และทำให้ลอจิกนำกลับมาใช้ใหม่ได้และทดสอบได้อย่างอิสระ

## รูปแบบอื่นที่มีประโยชน์สำหรับแอปขนาดใหญ่

```text
✓ Action classes — a single class per use-case (e.g. CreateUserAction) — very focused
✓ Form Requests — extract validation + authorization out of controllers
✓ API Resources — control response shape, separate from models
✓ Repository pattern — abstract data access behind interfaces (when you need it;
  often Eloquent suffices, so don't add it reflexively)
✓ Events/listeners — decouple side effects from core logic
✓ Domain-oriented organization — group code by feature/domain, not just by type
  (e.g. a modules/ structure) as the app grows
✓ Dependency injection + interfaces — for loose coupling and testability
```

## หลักการชี้นำ

```text
✓ Thin controllers (HTTP only) → services/actions (business logic) → models (data)
✓ Single Responsibility — each class does one thing
✓ Depend on abstractions (interfaces) for testability and flexibility
✗ Don't over-engineer — add layers when complexity justifies them, not prematurely
```

## ทำไมจึงสำคัญ

การเข้าใจวิธีจัดโครงสร้างแอปพลิเคชัน Laravel ขนาดใหญ่เป็นความรู้ระดับ senior ที่สำคัญ เพราะแนวทางที่ใช้ได้ดีกับแอปขนาดเล็ก (ลอจิกใน controllers และ models) จะพังเมื่อขยายขนาด นำไปสู่ controllers ที่บวม models ที่เป็น "god object" ลอจิกที่ซ้ำซ้อน และโค้ดที่ทดสอบและดูแลรักษายาก

การรู้เลเยอร์สถาปัตยกรรมเพิ่มเติม โดยเฉพาะ **service classes** (ห่อหุ้ม business logic เพื่อรักษาให้ controllers บางและ models โฟกัส ในขณะที่ทำให้ลอจิกนำกลับมาใช้ใหม่ได้และทดสอบได้) บวกกับ action classes, Form Requests (แยก validation/authorization), API Resources (ควบคุม output), repository pattern (abstract การเข้าถึงข้อมูลเมื่อจำเป็น), events (decouple side effects) และ **การจัดระเบียบแบบ domain-oriented** (จัดกลุ่มตามฟีเจอร์เมื่อแอปเติบโต) คือสิ่งที่ช่วยให้คุณสร้างแอปพลิเคชันที่ดูแลรักษาได้และขยายขนาดได้

หลักการชี้นำมีความสำคัญ ได้แก่ การแบ่งเลเยอร์ **thin controllers → services → models** หลัก single responsibility และการพึ่งพา abstractions (interfaces) เพื่อความสามารถในการทดสอบและ loose coupling

ที่สำคัญพอ ๆ กันคือการใช้วิจารณญาณในการ **ไม่ over-engineer** เพิ่มเลเยอร์เมื่อความซับซ้อนสมเหตุสมผลจริง ๆ มากกว่าการเพิ่มก่อนเวลา (ค่าเริ่มต้นของ Laravel เพียงพอสำหรับแอปที่ง่ายกว่า และการเพิ่ม repositories/abstractions โดยอัตโนมัติเพิ่มความซับซ้อนที่ไม่จำเป็น)

การเข้าใจรูปแบบสถาปัตยกรรมเหล่านี้และหลักการ (รวมถึงความยับยั้งชั่งใจ) ในการนำมาใช้ มีค่าสำหรับการสร้างแอปพลิเคชัน Laravel ขนาดใหญ่ที่มีอายุยืนยาวซึ่งยังคงดูแลรักษาได้ ทดสอบได้ และเข้าใจได้เมื่อมันเติบโต ซึ่งแยกแยะนักพัฒนาที่สามารถออกแบบสถาปัตยกรรมแอปพลิเคชันที่ขยายขนาดได้ออกจากผู้ที่แอปที่กำลังเติบโตของพวกเขาพังทลายลงเป็นโค้ดที่พันกันยุ่งเหยิงและดูแลรักษายาก

วิจารณญาณด้านสถาปัตยกรรมนี้เป็นเครื่องหมายของการพัฒนา Laravel ระดับ senior และเป็นข้อกังวลที่เกี่ยวข้องบ่อยสำหรับแอปพลิเคชันที่จริงจังและกำลังเติบโต

ปัญหา: ลอจิกไปอยู่ผิดที่

service classes — ห่อหุ้ม business logic

รูปแบบอื่นที่มีประโยชน์สำหรับแอปขนาดใหญ่

หลักการชี้นำ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง