آپ ایک بڑی Laravel ایپ کے لیے سروس/آرکیٹیکچر کو کیسے ترتیب دیتے ہیں؟

Question

Accepted Answer

جیسے جیسے Laravel ایپ لیکیشن بڑی ہوتی ہے، ڈیفالٹ "fat controller / fat model" انجام تک پہنچنا مشکل ہو جاتا ہے۔ بڑی ایپ لیکیشنز **اضافی آرکیٹیکچرل لیئرز** سے فائدہ اٹھاتی ہیں — service classes، action classes، repositories، form requests، اور واضح domain organization — business logic کو منظم، testable، اور maintainable رکھنے کے لیے۔

## مسئلہ: منطق غلط جگہوں میں ختم ہو جاتی ہے

```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 کو encapsulate کریں

```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 کو thin رکھتے ہیں (صرف HTTP سنبھالنا) اور models کو data پر focused رکھتے ہیں — اور منطق کو reusable اور independently testable بناتے ہیں۔

## بڑی ایپ لیکیشنز کے لیے دوسرے مفید patterns

```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-level knowledge ہے، کیونکہ وہ conventions جو چھوٹی ایپلیکیشنز کے لیے کام کرتے ہیں (logic controllers اور models میں) بڑے پیمانے پر ٹوٹ جاتے ہیں — جس سے bloated controllers، "god" models، duplicated logic، اور code جو test اور maintain کرنا مشکل ہے پیدا ہوتا ہے۔

اضافی آرکیٹیکچرل لیئرز کو جاننا — خاص طور پر **service classes** (business logic کو encapsulate کرنا تاکہ controllers thin رہیں اور models focused رہیں، جبکہ logic reusable اور testable ہو)، اس کے علاوہ action classes، Form Requests (validation/authorization کو نکالنا)، API Resources (output کو control کرنا)، repository pattern (data access کو abstract کرنا جب ضروری ہو)، events (side effects کو decouple کرنا)، اور **domain-oriented organization** (feature کے لحاظ سے grouping جیسے ایپ بڑی ہوتی ہے) — یہی آپ کو maintainable، scalable applications بنانے دیتا ہے۔

رہنمائی کے اصول اہم ہیں: **thin controllers → services → models** layering، single responsibility، اور abstractions (interfaces) پر منحصر ہونا testability اور loose coupling کے لیے۔

برابر اہم یہ فیصلہ ہے کہ **over-engineer نہ کریں** — جب complexity واقعی layers کو justify کرے تب ان کو شامل کریں نہ کہ پہلے سے (Laravel کی defaults سادہ ایپس کے لیے ٹھیک ہیں، اور بے سوچ سمجھ repositories/abstractions شامل کرنا needless complexity شامل کرتا ہے)۔

ان آرکیٹیکچرل patterns اور ان کو apply کرنے کے اصولوں (اور restraint) کو سمجھنا بڑی، long-lived Laravel ایپلیکیشنز بنانے کے لیے قیمتی ہے جو maintainable، testable، اور comprehensible رہیں جیسے وہ بڑی ہوں — ایسے developers کو علیحدہ کرتے ہوئے جو scalable applications کو architect کر سکتے ہیں ان سے جن کی بڑھتی ایپلیکیشنز tangled، hard-to-maintain code میں collapse ہو جاتی ہیں۔

yہ آرکیٹیکچرل judgment senior Laravel development کی خصوصیت ہے اور serious، growing applications کے لیے بار بار relevant خیال ہے۔