¿Cómo estructuras un servicio/arquitectura para una aplicación Laravel grande?

Question

Accepted Answer

A medida que una aplicación Laravel crece, el enfoque predeterminado de "controlador gordo / modelo gordo" se vuelve difícil de mantener. Las aplicaciones más grandes se benefician de **capas arquitectónicas adicionales** — clases de servicio, clases de acción, repositorios, form requests y una organización de dominio clara — para mantener la lógica empresarial organizada, comprobable y mantenible.

## El problema: la lógica termina en los lugares equivocados

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

## Clases de servicio — encapsular lógica empresarial

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

**Las clases de servicio** contienen lógica empresarial, manteniendo los controladores delgados (solo manejando HTTP) y los modelos enfocados en datos — y haciendo que la lógica sea reutilizable y comprobable independientemente.

## Otros patrones útiles para aplicaciones grandes

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

## Los principios guía

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

## Por qué es importante

Entender cómo estructurar una aplicación Laravel grande es conocimiento importante de nivel senior, porque las convenciones que funcionan para aplicaciones pequeñas (lógica en controladores y modelos) se desmoronan a escala — generando controladores hinchados, modelos "todopoderosos", lógica duplicada y código que es difícil de probar y mantener.

Conocer las capas arquitectónicas adicionales — especialmente **clases de servicio** (encapsulando lógica empresarial para mantener los controladores delgados y los modelos enfocados, mientras se hace que la lógica sea reutilizable y comprobable), más clases de acción, Form Requests (extrayendo validación/autorización), API Resources (controlando salida), el patrón repositorio (abstrayendo acceso a datos cuando es necesario), eventos (desacoplando efectos secundarios) y **organización orientada al dominio** (agrupación por característica a medida que la aplicación crece) — es lo que te permite construir aplicaciones mantenibles y escalables.

Los principios guía importan: capas de **controladores delgados → servicios → modelos**, responsabilidad única y depender de abstracciones (interfaces) para comprobabilidad y bajo acoplamiento.

Igualmente importante es el juicio para **no sobre-ingenierizar** — agregar capas cuando la complejidad genuinamente las justifique en lugar de hacerlo prematuramente (los valores predeterminados de Laravel están bien para aplicaciones más simples, y agregar reflexivamente repositorios/abstracciones añade complejidad innecesaria).

Entender estos patrones arquitectónicos y los principios (y moderación) para aplicarlos es valioso para construir aplicaciones Laravel grandes y duraderas que sigan siendo mantenibles, comprobables y comprensibles a medida que crecen — diferenciando a desarrolladores que pueden arquitectar aplicaciones escalables de aquellos cuyas aplicaciones en crecimiento colapsan en código enredado y difícil de mantener.

Este juicio arquitectónico es una característica distintiva del desarrollo Laravel senior y una preocupación frecuentemente relevante para aplicaciones serias en crecimiento.