Macam Mana Aku Engineer Laravel App Besar Tanpa Jadi Coding Spaghetti

Bila Laravel app makin besar, masalah bukan framework.
Masalah biasanya kita campur semua benda dalam satu tempat.

Controller gemuk.
Business logic bersepah.
Nak tambah feature → takut rosakkan benda lain.

Ini cara aku fikir dan susun Laravel app supaya boleh scale tanpa sakit kepala.

Prinsip #1: Controller Bukan Tempat Berfikir

Controller hanya orchestration, bukan tempat buat keputusan.

❌ Salah (common mistake)

public function store(Request $request)
{
    $user = User::create($request->all());
    if ($request->has('referral_code')) 
    {
        $ref = Referral::where('code', $request->referral_code)->first();
        $ref->increment('total_used');
    }

    Mail::to($user->email)->send(new WelcomeMail($user));

    return redirect()->back();
}

Controller jadi tempat:

• validate

• create user

• referral logic

• email logic

Ini bukan scalable.

Prinsip #2: Business Logic = Action / Service Class

Aku selalu tanya:

“Kalau esok aku nak trigger logic ni dari Queue / Event / Console — boleh ke?”

Kalau jawapan tak boleh, code tu salah tempat.

✅ Betul

class RegisterUserAction 
{
    public function execute(array $data): User
    {
        $user = User::create($data);
        if (!empty($data['referral_code'])) 
        {
				    app(ApplyReferralAction::class)->execute($user,$data['referral_code']);
        }
			
        event(new UserRegistered($user));
        
        return $user;
    } 
}

Controller jadi nipis:

public function store(RegisterRequest $request)
{
    app(RegisterUserAction::class)
        ->execute($request->validated());
    
    return back();
}

Sekarang:

• boleh reuse

• boleh test

• boleh evolve

Prinsip #3: Fikir Ikut “Flow Bisnes”, Bukan Ikut Folder Laravel

Aku tak mula dengan folder.
Aku mula dengan soalan:

“Flow dia apa sebenarnya?”

Contoh:

User daftar → referral dikira → email dihantar → commission update

Struktur aku biasanya jadi macam ni:

app/  
├── Actions/  
│    ├── RegisterUserAction.php
│    ├── ApplyReferralAction.php
│
├── Events/
│    └── UserRegistered.php  
│
├── Listeners/
│    ├── SendWelcomeEmail.php  
│    └── CalculateCommission.php`

Laravel bagi kebebasan.
Gunakan untuk reflect cara bisnes bergerak, bukan ikut tutorial atau buku semata-mata.

Prinsip #4: Event & Queue Bukan “Nice to Have”

Kalau logic tu:

• ambil masa

• tak perlu tunggu user

• bukan critical path

👉 Queue it.

class SendWelcomeEmail implements ShouldQueue 
{
    public function handle(UserRegistered $event)
    {
        Mail::to($event->user->email)->send(new WelcomeMail($event->user));
		}
}

Kesan terus:

• request jadi laju

• server tak terbeban

• user experience naik

Prinsip #5: Jangan Over-Engineering Awal-awal

Ini perangkap startup.

❌ Tak betul

• Domain Driven Design terlalu awal

• 20 abstraction layer untuk CRUD simple

• Pattern ikut buku, bukan ikut masalah

✅ Kacak

• Start simple

• Bila mula rasa sakit → refactor

• Architecture evolve ikut complexity sebenar

Laravel memang direka untuk refactor dengan selamat.

Cara Aku Berfikir (Ringkas Tapi Praktikal)

Setiap kali nak tulis code, aku tanya:

1. Logic ni akan digunakan di mana lagi?

2. Kalau flow bisnes berubah, apa paling senang disentuh?

3. Controller aku boleh jadi 10–20 baris tak?

Kalau jawapan nampak messy → aku revise dan susun balik.

Penutup

Spaghetti code bukan sebab Laravel.
Ia sebab:

• logic bercampur semua
• flow tak jelas
• terlalu cepat kejar feature (guna agile ke tu~)

Architecture yang baik tak nampak “smart”,
tapi nampak tenang bila app dah besar.

Kalau kau bina app untuk survive 3–5 tahun,
susun dari sekarang — bukan bila dah sakit.