Bagaimana anda menstruktur perkhidmatan/seni bina untuk aplikasi Laravel yang besar?

Question

Accepted Answer

Apabila aplikasi Laravel berkembang, pendekatan lalai "fat controller / fat model" menjadi sukar diselenggara. Aplikasi yang lebih besar mendapat manfaat daripada **lapisan seni bina tambahan** — kelas service, kelas action, repository, form request, dan organisasi domain yang jelas — untuk memastikan logik perniagaan tersusun, boleh diuji, dan boleh diselenggara.

## Masalah: logik berakhir di tempat yang salah

```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.
```

## Kelas service — merangkumkan logik perniagaan

```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());
}
```

**Kelas service** menyimpan logik perniagaan, memastikan controller nipis (hanya mengendalikan HTTP) dan model fokus pada data — dan menjadikan logik boleh diguna semula serta boleh diuji secara bebas.

## Corak berguna lain untuk aplikasi besar

```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
```

## Prinsip panduan

```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
```

## Mengapa ia penting

Memahami cara menstruktur aplikasi Laravel yang besar ialah pengetahuan peringkat senior yang penting, kerana konvensyen yang berfungsi untuk aplikasi kecil (logik dalam controller dan model) runtuh pada skala — membawa kepada controller yang membengkak, model "god", logik yang berganda, dan kod yang sukar diuji dan diselenggara.

Mengetahui lapisan seni bina tambahan — terutamanya **kelas service** (merangkumkan logik perniagaan untuk memastikan controller nipis dan model fokus, sambil menjadikan logik boleh diguna semula dan boleh diuji), ditambah kelas action, Form Request (mengekstrak pengesahihan/kebenaran), API Resource (mengawal output), corak repository (mengabstrak akses data apabila diperlukan), event (memisahkan kesan sampingan), dan **organisasi berorientasikan domain** (mengumpulkan mengikut ciri apabila aplikasi berkembang) — ialah apa yang membolehkan anda membina aplikasi yang boleh diselenggara dan boleh skala.

Prinsip panduan adalah penting: lapisan **controller nipis → service → model**, single responsibility, dan bergantung pada abstraksi (interface) untuk kebolehujian dan gandingan longgar.

Sama penting ialah pertimbangan untuk **tidak melebih-lebihkan kejuruteraan** — menambah lapisan apabila kerumitan benar-benar mewajarkannya berbanding terlalu awal (lalai Laravel memadai untuk aplikasi yang lebih ringkas, dan menambah repository/abstraksi secara refleks menambah kerumitan yang tidak perlu).

Memahami corak seni bina ini dan prinsip (serta penahanan diri) untuk menggunakannya bernilai untuk membina aplikasi Laravel yang besar dan bertahan lama yang kekal boleh diselenggara, boleh diuji, dan boleh difahami apabila ia berkembang — membezakan pembangun yang boleh merangka seni bina aplikasi yang boleh skala daripada mereka yang aplikasinya yang berkembang runtuh menjadi kod yang berkusut dan sukar diselenggara.

Pertimbangan seni bina ini ialah ciri khas pembangunan Laravel senior dan satu kebimbangan yang kerap relevan untuk aplikasi serius yang berkembang.