{"id":311,"date":"2026-07-14T16:15:07","date_gmt":"2026-07-14T23:15:07","guid":{"rendered":"https:\/\/www.mariatech.com.mx\/blog\/?p=311"},"modified":"2026-07-14T16:15:07","modified_gmt":"2026-07-14T23:15:07","slug":"arquitectura-de-un-proyecto-de-laravel","status":"publish","type":"post","link":"https:\/\/www.mariatech.com.mx\/blog\/laravel-php\/arquitectura-de-un-proyecto-de-laravel\/","title":{"rendered":"Arquitectura de un proyecto de Laravel"},"content":{"rendered":"\n

Cuando un proyecto Laravel empieza a crecer, una de las primeras se\u00f1ales de desorden aparece en los controladores: m\u00e9todos cada vez m\u00e1s largos, validaciones mezcladas con consultas, reglas de negocio dentro del mismo archivo y operaciones repetidas en varias partes del sistema.<\/p>\n\n\n\n

Al inicio puede parecer pr\u00e1ctico resolver todo dentro del controller, pero con el tiempo esa decisi\u00f3n vuelve m\u00e1s dif\u00edcil mantener, probar y escalar el proyecto. Por eso conviene separar responsabilidades entre Controllers<\/strong>, Form Requests<\/strong>, Services<\/strong> y Models<\/strong>.<\/p>\n\n\n\n

La idea no es complicar la arquitectura, sino poner cada pieza en el lugar correcto.<\/p>\n\n\n\n

\n\n\n\n

Resumen r\u00e1pido<\/h2>\n\n\n\n

Una forma sencilla de entenderlo es esta:<\/p>\n\n\n\n

Elemento<\/th>Responsabilidad principal<\/th><\/tr><\/thead>
Controller<\/td>Controla el flujo HTTP: recibe la petici\u00f3n, llama lo necesario y responde.<\/td><\/tr>
Form Request<\/td>Valida y prepara los datos antes de llegar al controller.<\/td><\/tr>
Service<\/td>Ejecuta la l\u00f3gica de negocio o procesos importantes del sistema.<\/td><\/tr>
Model<\/td>Representa una tabla, relaciones, atributos, scopes y comportamiento simple de la entidad.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

En otras palabras:<\/p>\n\n\n\n

Request\n  \u2193\nForm Request\n  \u2193\nController\n  \u2193\nService\n  \u2193\nModel \/ Base de datos\n  \u2193\nResponse<\/code><\/pre>\n\n\n\n
\n\n\n\n
Qu\u00e9 es un Controller en Laravel<\/h2>\n\n\n\n
Un controller agrupa la l\u00f3gica que responde a peticiones HTTP relacionadas con un recurso. Laravel recomienda usarlos para organizar el manejo de solicitudes que, de otra forma, terminar\u00edan como closures dentro de las rutas.<\/p>\n\n\n\n
El controller debe actuar como coordinador. No deber\u00eda cargar toda la l\u00f3gica de negocio del sistema.<\/p>\n\n\n\n
Responsabilidades recomendadas de un controller<\/h3>\n\n\n\n
    \n
  • Recibir la petici\u00f3n.<\/li>\n\n\n\n
  • Usar un Form Request para validar.<\/li>\n\n\n\n
  • Buscar un modelo cuando sea algo simple.<\/li>\n\n\n\n
  • Llamar un Service cuando haya l\u00f3gica de negocio.<\/li>\n\n\n\n
  • Regresar una vista, redirect o respuesta JSON.<\/li>\n<\/ul>\n\n\n\n
    Ejemplo de controller limpio<\/h3>\n\n\n\n
    public function update(UpdateProductRequest $request, string $product)\n{\n    $product = Product::find($product);\n\n    $product = $this->productService->update(\n        $product,\n        $request->validated()\n    );\n\n    return response()->json([\n        'success' => true,\n        'message' => 'Producto actualizado correctamente.',\n        'product' => [\n            'id' => $product->id,\n            'name' => $product->name,\n        ],\n    ]);\n}<\/code><\/pre>\n\n\n\n
    Este controller no sabe todos los detalles de c\u00f3mo se actualiza el producto. Solo controla el flujo.<\/p>\n\n\n\n
    Eso lo hace m\u00e1s f\u00e1cil de leer, mantener y modificar.<\/p>\n\n\n\n
    \n\n\n\n
    Qu\u00e9 es un Form Request<\/h2>\n\n\n\n
    Un Form Request es una clase especializada para validar y autorizar datos de entrada. Laravel permite crear estos archivos para encapsular validaci\u00f3n y autorizaci\u00f3n en un lugar separado del controller.<\/p>\n\n\n\n
    Esto evita que el controller se llene de reglas como required<\/code>, exists<\/code>, max<\/code>, email<\/code>, validaciones condicionales o preparaci\u00f3n de datos.<\/p>\n\n\n\n
    Responsabilidades recomendadas de un Form Request<\/h3>\n\n\n\n
      \n
    • Validar campos requeridos.<\/li>\n\n\n\n
    • Validar formatos.<\/li>\n\n\n\n
    • Validar existencia de registros en base de datos.<\/li>\n\n\n\n
    • Preparar datos antes de validar.<\/li>\n\n\n\n
    • Autorizar si el usuario puede ejecutar la acci\u00f3n.<\/li>\n<\/ul>\n\n\n\n
      Ejemplo de Form Request<\/h3>\n\n\n\n
      class UpdateProductRequest extends FormRequest\n{\n    public function rules(): array\n    {\n        return [\n            'product_id' => ['required', 'integer', 'exists:products,id'],\n            'name' => ['required', 'string', 'max:255'],\n            'price' => ['required', 'numeric', 'min:0'],\n        ];\n    }\n\n    public function authorize(): bool\n    {\n        return true;\n    }\n}<\/code><\/pre>\n\n\n\n
      El controller ya no necesita preocuparse por esa preparaci\u00f3n.<\/p>\n\n\n\n
      \n\n\n\n
      Qu\u00e9 es un Service<\/h2>\n\n\n\n
      Un Service es una clase donde se concentra la l\u00f3gica de negocio o los procesos importantes del sistema. Aunque Laravel no obliga a crear una carpeta Services<\/code>, el framework s\u00ed facilita este patr\u00f3n gracias a su Service Container y a la inyecci\u00f3n de dependencias.<\/p>\n\n\n\n
      La pregunta clave para decidir si algo va a un Service es:<\/p>\n\n\n\n
      \n
      \u00bfEsto solo controla una petici\u00f3n HTTP o representa una operaci\u00f3n importante del negocio?<\/p>\n<\/blockquote>\n\n\n\n
      Si representa una operaci\u00f3n del negocio, normalmente conviene moverlo a un Service.<\/p>\n\n\n\n
      Responsabilidades recomendadas de un Service<\/h3>\n\n\n\n
        \n
      • Crear registros.<\/li>\n\n\n\n
      • Actualizar registros.<\/li>\n\n\n\n
      • Eliminar registros.<\/li>\n\n\n\n
      • Ejecutar transacciones.<\/li>\n\n\n\n
      • Aplicar reglas de negocio.<\/li>\n\n\n\n
      • Coordinar varias tablas.<\/li>\n\n\n\n
      • Calcular importes, descuentos, comisiones o estados.<\/li>\n\n\n\n
      • Consumir APIs externas.<\/li>\n\n\n\n
      • Disparar notificaciones, eventos o procesos relacionados.<\/li>\n<\/ul>\n\n\n\n
        Ejemplo de Service<\/h3>\n\n\n\n
        class ProductService\n{\n    public function create(array $data): Product\n    {\n        return DB::transaction(function () use ($data) {\n            return Product::create([\n                'name' => $data['name'],\n                'description' => $data['description'] ?? null,\n                'price' => $data['price'],\n                'enabled' => $data['enabled'] ?? true,\n            ]);\n        });\n    }\n\n    public function update(Product $product, array $data): Product\n    {\n        return DB::transaction(function () use ($product, $data) {\n            $product->name = $data['name'];\n            $product->description = $data['description'] ?? null;\n            $product->price = $data['price'];\n            $product->enabled = $data['enabled'] ?? $product->enabled;\n            $product->save();\n\n            return $product->fresh();\n        });\n    }\n\n    public function delete(Product $product): void\n    {\n        DB::transaction(function () use ($product) {\n            $product->delete();\n        });\n    }\n}<\/code><\/pre>\n\n\n\n
        Aunque algunos m\u00e9todos parezcan simples al inicio, tenerlos en un Service permite que crezcan ordenadamente. Hoy un delete()<\/code> puede borrar un registro; ma\u00f1ana puede validar permisos internos, eliminar relaciones, registrar historial y disparar una notificaci\u00f3n.<\/p>\n\n\n\n
        \n\n\n\n
        Qu\u00e9 es un Model en Laravel<\/h2>\n\n\n\n
        Un Model representa una tabla de base de datos dentro de Eloquent. Laravel indica que cada tabla suele tener un modelo correspondiente, y que estos modelos permiten consultar, insertar, actualizar y eliminar registros.<\/p>\n\n\n\n
        Pero eso no significa que toda la l\u00f3gica de negocio deba vivir dentro del Model.<\/p>\n\n\n\n
        Responsabilidades recomendadas de un Model<\/h3>\n\n\n\n
          \n
        • Definir la tabla si no sigue la convenci\u00f3n.<\/li>\n\n\n\n
        • Definir campos fillable<\/code> o guarded<\/code>.<\/li>\n\n\n\n
        • Definir relaciones.<\/li>\n\n\n\n
        • Definir casts.<\/li>\n\n\n\n
        • Crear accessors y mutators.<\/li>\n\n\n\n
        • Crear scopes reutilizables.<\/li>\n\n\n\n
        • Agregar m\u00e9todos simples propios de la entidad.<\/li>\n<\/ul>\n\n\n\n
          Ejemplo de Model<\/h3>\n\n\n\n
          class Product extends Model\n{\n    protected $fillable = [\n        'name',\n        'description',\n        'price',\n        'enabled',\n    ];\n\n    protected function casts(): array\n    {\n        return [\n            'price' => 'decimal:2',\n            'enabled' => 'boolean',\n        ];\n    }\n\n    public function scopeEnabled($query)\n    {\n        return $query->where('enabled', true);\n    }\n\n    public function isAvailable(): bool\n    {\n        return $this->enabled === true;\n    }\n}<\/code><\/pre>\n\n\n\n
          Este tipo de l\u00f3gica s\u00ed pertenece al modelo porque describe el comportamiento directo de la entidad Product<\/code>.<\/p>\n\n\n\n
          En cambio, si el proceso implica cobrar, registrar historial, enviar notificaciones y actualizar varias tablas, eso ya deber\u00eda ir a un Service.<\/p>\n\n\n\n
          \n\n\n\n
          Cu\u00e1ndo usar cada uno<\/h2>\n\n\n\n
          Usa Controller cuando…<\/h3>\n\n\n\n