对于大型 Laravel 应用，你会如何组织服务/架构？

Question

Accepted Answer

随着 Laravel 应用不断增长，默认的"臃肿控制器 / 臃肿模型"（fat controller / fat model）方式会变得难以维护。较大的应用受益于**额外的架构分层**——service 类、action 类、repository、form request 以及清晰的领域划分——以便让业务逻辑保持有组织、可测试且易于维护。

## 问题：逻辑被放在了错误的地方

```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 类——封装业务逻辑

```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 类**承载业务逻辑，让控制器保持轻量（只负责处理 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 应用是重要的高级（senior）层级知识，因为适用于小型应用的惯例（把逻辑放在控制器和模型中）在规模扩大时会失效——导致控制器臃肿、出现"上帝（god）"模型、逻辑重复，以及难以测试和维护的代码。

掌握这些额外的架构分层——尤其是 **service 类**（封装业务逻辑，让控制器保持轻量、让模型保持专注，同时使逻辑可复用、可测试），加上 action 类、Form Request（抽离校验/授权）、API Resource（控制输出）、repository 模式（在需要时抽象数据访问）、事件（解耦副作用），以及**面向领域的组织方式**（随着应用增长按功能分组）——正是让你能够构建可维护、可扩展应用的关键。

这些指导原则很重要：**thin controllers → services → models** 的分层、单一职责，以及为可测试性和松耦合而依赖抽象（接口）。

同样重要的是**不要过度设计**（over-engineer）的判断力——在复杂度确实需要时才增加分层，而不是过早引入（对于较简单的应用，Laravel 的默认方式就足够了，反射式地引入 repository/抽象只会增加不必要的复杂度）。

理解这些架构模式以及应用它们的原则（与克制），对于构建大型、长生命周期的 Laravel 应用很有价值，能让它们在增长过程中始终保持可维护、可测试和易于理解——这区分了能够架构可扩展应用的开发者与那些应用不断增长却最终坍塌为纠缠不清、难以维护代码的开发者。

这种架构判断力是高级 Laravel 开发的标志，也是认真对待、持续增长的应用经常需要关注的问题。