பெரிய Laravel பயன்பாட்டிற்கான சேவை/கட்டமைப்பை எவ்வாறு கட்டமைப்பீர்கள்?

Question

Accepted Answer

Laravel பயன்பாடு வளரும்போது, இயல்புநிலை "fat controller / fat model" முறைமை பராமரிக்க கடினமாகிறது. பெரிய பயன்பாடுகள் **கூடுதல் கட்டமைப்பு அடுக்குகளிலிருந்து** பயனடைகின்றன — service classes, action classes, repositories, form requests, மற்றும் தெளிவான domain organization — ஆ, வணிக தர்க்கத்தை ஒரு வழிபாட்டாக, சோதனையாக, மற்றும் பராமரிக்கக்கூடிய வகையில் வைத்திருக்க.

## சிக்கல்: தர்க்கம் தவறான இடங்களில் முடிந்து விடுகிறது

```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 — வணிக தர்க்கத்தை உள்ளிடுக

```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** வணிக தர்க்கத்தை வைத்திருக்கின்றன, 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,