तपाई एक ठूलो Laravel अनुप्रयोगको लागि सेवा/आर्किटेक्चर कसरी संरचना गर्नुहुन्छ?

Question

IT Interview Practice · 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 अनुप्रयोगलाई कसरी संरचना गर्ने भनेर बुझ्नु वरिष्ठ-स्तरीय ज्ञान हो, किनभने सानो अनुप्रयोगहरूको लागि काम गर्ने सम्मेलनहरू (controllers र models मा तर्क) स्केलमा विफल हुन्छन् — बढी हुएको controllers, "god" models, दोहोरिएको तर्क, र कोड जो परीक्षण र राखरखाव गर्न गाह्रो छ।

अतिरिक्त आर्किटेक्चरल तहहरू जान्नु — विशेष गरी **service classes** (व्यावसायिक तर्क समावेश गर्दै controllers लाई पातलो र models लाई केन्द्रित राख्छन्, जबकि तर्कलाई पुन: प्रयोगयोग्य र परीक्षणयोग्य बनाउँछन्), साथै action classes, Form Requests (validation/authorization निकाल्दै), API Resources (आउटपुट नियन्त्रण गर्दै), repository pattern (डेटा पहुँच अलग गर्दै जब आवश्यक छ), events (साइड इफेक्टहरू अलग गर्दै), र **domain-oriented organization** (अनुप्रयोग बढ्दै जाँदा feature द्वारा समूहीकरण गर्दै) — यो हो जसले तपाईलाई राखरखावयोग्य, स्केलेबल अनुप्रयोगहरू निर्माण गर्न दिन्छ।

मार्गदर्शक सिद्धान्तहरू महत्वपूर्ण छन्: **thin controllers → services → models** तहीकरण, एकल जिम्मेवारी, र अमूर्ततामा निर्भर हुनु (interfaces) परीक्षणयोग्यता र ढीलो coupling को लागि।

समान महत्वपूर्ण **अति-इञ्जीनियरिङ नगर्नु** हो — जटिलतालाई वास्तवमा न्याय गर्दा तहहरू जोड्दै बरु पूर्वनिर्धारितमा (Laravel को डिफल्टहरू सरल अनुप्रयोगहरूको लागि ठिक छन्, र प्रतिक्रिया रूपमा repositories/abstractions जोड्नु अनावश्यक जटिलता थप्छ)।

यी आर्किटेक्चरल प्याटर्नहरू र तिनलाई लागू गर्ने सिद्धान्तहरू (र संयम) बुझ्नु ठूलो, लामो-जीवन Laravel अनुप्रयोगहरू निर्माण गर्नको लागि मूल्यवान छ जो राखरखावयोग्य, परीक्षणयोग्य र समझदारी योग्य रहन्छन् जब तिनीहरू बढ्छन् — विकाससीमा सक्षम डेभलपरहरूलाई भेद गर्दै जो स्केलेबल अनुप्रयोगहरू आर्किटेक्ट गर्न सक्छन् तिनीहरूबाट जसको बढ्दो अनुप्रयोगहरू गडबडिएको, राखरखाव गर्न गाह्रो कोडमा पतन हुन्छन्।

यो आर्किटेक्चरल निर्णय वरिष्ठ Laravel विकासको एक हलचल र गम्भीर, बढ्दो अनुप्रयोगहरूको लागि बारम्बार प्रासंगिक चिन्ता हो।

समस्या: तर्क गलत जागायमा समाप्त हुन्छ

Service classes — व्यावसायिक तर्क समावेश गर्नुहोस्

ठूलो अनुप्रयोगहरूको लागि अन्य उपयोगी प्याटर्नहरू

मार्गदर्शक सिद्धान्तहरू

यो किन महत्वपूर्ण छ

सम्बन्धित प्रश्नहरू