كيف تنظم الخدمة/البنية المعمارية لتطبيق Laravel كبير؟

Question

Accepted Answer

عندما ينمو تطبيق Laravel، يصبح النهج الافتراضي "المتحكم الضخم / النموذج الضخم" صعب الصيانة. التطبيقات الأكبر تستفيد من **طبقات معمارية إضافية** — فئات الخدمة، فئات الإجراء، المستودعات، طلبات النماذج، والتنظيم الواضح للمجال — للحفاظ على منطق العمل منظماً وقابلاً للاختبار والصيانة.

## المشكلة: ينتهي المنطق في الأماكن الخاطئة

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

## فئات الخدمة — تغليف منطق العمل

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

**فئات الخدمة** تحتوي على منطق العمل، مما يجعل المتحكمات رقيقة (تتعامل فقط مع HTTP) والنماذج تركز على البيانات — وتجعل المنطق قابلاً لإعادة الاستخدام وقابلاً للاختبار بشكل مستقل.

## أنماط مفيدة أخرى للتطبيقات الكبيرة

```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 كبير هو معرفة حاسمة على مستوى الخبراء، لأن الاتفاقيات التي تعمل للتطبيقات الصغيرة (المنطق في المتحكمات والنماذج) تنهار عند التوسع — مما يؤدي إلى متحكمات منتفخة، نماذج "إله"، منطق مكرر، وكود يصعب اختباره والحفاظ عليه.

معرفة الطبقات المعمارية الإضافية — خاصة **فئات الخدمة** (تغليف منطق العمل لجعل المتحكمات رقيقة والنماذج مركزة، مع جعل المنطق قابلاً لإعادة الاستخدام والاختبار)، بالإضافة إلى فئات الإجراء، طلبات النماذج (استخراج التحقق/التفويض)، موارد API (التحكم في الإخراج)، نمط المستودع (تجريد الوصول للبيانات عند الحاجة)، الأحداث (فصل التأثيرات الجانبية)، و**التنظيم الموجه بالمجال** (التجميع حسب الميزة مع نمو التطبيق) — هو ما يسمح لك ببناء تطبيقات قابلة للصيانة والتوسع.

المبادئ التوجيهية مهمة: طبقات **متحكمات رقيقة → خدمات → نماذج**، المسؤولية الفردية، والاعتماد على الحروف المجردة (الواجهات) لسهولة الاختبار والربط الضعيف.

ما يساوي الأهمية هو الحكم بعدم **الإفراط في الهندسة** — إضافة طبقات عندما يبررها التعقيد الفعلي بدلاً من القيام بها مسبقاً (قيم Laravel الافتراضية كافية للتطبيقات الأبسط، والإضافة بشكل انعكاسي للمستودعات/الحروف المجردة تضيف تعقيداً غير ضروري).

فهم هذه الأنماط المعمارية والمبادئ (والاعتدال) لتطبيقها له قيمة حقيقية في بناء تطبيقات Laravel كبيرة وطويلة العمر التي تبقى قابلة للصيانة والاختبار والفهم مع نموها — مما يميز المطورين الذين يمكنهم بناء تطبيقات قابلة للتوسع عن أولئك الذين تنهار تطبيقاتهم المتنامية إلى كود معقد وصعب الصيانة.

هذا الحكم المعماري هو سمة مميزة لتطوير Laravel الكبار وموضوع ذو صلة متكررة للتطبيقات الجادة والنامية.